BRPI0809501A2 - Sistema de comunicação de token bus - Google Patents
Sistema de comunicação de token bus Download PDFInfo
- Publication number
- BRPI0809501A2 BRPI0809501A2 BRPI0809501-9A BRPI0809501A BRPI0809501A2 BR PI0809501 A2 BRPI0809501 A2 BR PI0809501A2 BR PI0809501 A BRPI0809501 A BR PI0809501A BR PI0809501 A2 BRPI0809501 A2 BR PI0809501A2
- Authority
- BR
- Brazil
- Prior art keywords
- token
- node
- bus
- packet
- data
- Prior art date
Links
- 238000004891 communication Methods 0.000 title claims description 15
- 238000000034 method Methods 0.000 claims abstract description 10
- 230000004044 response Effects 0.000 claims description 37
- 230000005540 biological transmission Effects 0.000 claims description 19
- 230000008569 process Effects 0.000 abstract description 5
- 238000001514 detection method Methods 0.000 description 14
- 238000004422 calculation algorithm Methods 0.000 description 3
- 230000006835 compression Effects 0.000 description 3
- 238000007906 compression Methods 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 239000000872 buffer Substances 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 235000013372 meat Nutrition 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000010845 search algorithm Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/407—Bus networks with decentralised control
- H04L12/417—Bus networks with decentralised control with deterministic access, e.g. token passing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/42—Loop networks
- H04L12/427—Loop networks with decentralised control
- H04L12/433—Loop networks with decentralised control with asynchronous transmission, e.g. token ring, register insertion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/403—Bus networks with centralised control, e.g. polling
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Multi Processors (AREA)
- Bus Control (AREA)
Description
" SISTEMA DE COMUNICAÇÃO DE TOKEN BUS "
CAMPO TÉCNICO DA PRESENTE INVENÇÃO
A presente invenção se refere a sistemas de comunicação e particularmente a um sistema de token bus primordialmente intencionado para proporcionar comunicação entre localizações submarinas.
PANORAMA DO ESTADO DA TÉCNICA DA PRESENTE INVENÇÃO
Em um sistema de comunicação de token bus, um token
lógico é utilizado como arbitrador para evitar conflito entre entidades (aqui chamadas nós) que lutam para acesso para o bus. Um nó que tem possessão do token é livre para enviar um pacote de dados para um outro nó por
especificação do endereço do nó de destino em um pacote transmitido. 0 nó de destino pode após isso transmitir um pacote de reconhecimento para o nó de fonte. 0 nó de fonte pode após isso transmitir um outro pacote de dados ou passa o token para frente para o próximo nó subseqüente. Se o
2 0 token é passado para frente, o nó de recepção pode
reconhecer recebimento. A presente invenção particularmente visa proporcionar um sistema de token bus com capacidade de resposta, dados de ponta a ponta (completos) e determinismo aperfeiçoados.
25
ESTABELECIMENTO DA PRESENTE INVENÇÃO
Em concordância com a presente invenção, uma rede de comunicação de token bus compreende uma multiplicidade de nós conectados por um bus comum, em que cada nó em
3 0 comunicação operativa com o bus é organizado para
transmitir, quando em possessão de um token e possuindo dados (payload) para transmitir, um pacote de ' token & dados' ('token & data') que inclui um payload e um header que especifica um primeiro endereço identificando que nó é para receber o token e um segundo endereço identificando que nó é para receber o payload. Cada nó é preferivelmente adicionalmente organizado para transmitir, quando em possessão do token, mas não possuindo nenhum dado para 5 transmitir, um pacote de 'token somente' sem um payload e incluindo um header que especifica um primeiro endereço identificando que nó é para receber o token. Tal pacote de 'token somente' preferivelmente especifica no lugar do segundo endereço um endereço identificando nenhum dos nós.
A presente invenção inclui um dispositivo de rede para
utilização como um nó em um tal sistema e um método de operação de um tal sistema.
BREVE RESUMO DA PRESENTE INVENÇÃO
Em uma forma prática da presente invenção, um nó com o
token pode transmitir sobre o bus um pacote que contém dois endereços de destino no pacote. Um endereço especifica o nó que deveria receber o componente de dados (payload) do pacote transmitido. 0 outro endereço especifica o nó que 20 deveria receber o token. A rede especifica aquele um nó com o token que deveria imediatamente transmitir um pacote contendo exatamente o token ou um pacote com token e dados se ele possui dados para enviar.
Quando nenhum dado está sendo passado a partir de um 25 nó para um outro nó sobre a rede, o token pode ser passado a partir de um nó para o próximo nó subseqüente em ordem. Cada nó irá passar o token para o próximo número de nó o mais alto subseqüente. Se um nó possui o token possuindo algum dado para enviar, ele transmite um pacote com o token
3 0 para o próximo nó subseqüente e dados para qualquer dos nós. O sistema de bus requer todos os nós para receber todos os pacotes e processar os mesmos para determinar se o token ou os dados (ou ambos) é destinado para os mesmos.
Efetivamente, duas mensagens estão sendo enviadas em um frame de tempo (pacote). Preferivelmente, para evitar contenção sobre o bus, nenhuns reconhecimentos de pacote recebidos são feitos. 0 sistema pode contar com protocolos de nível mais altos para verificar que dados foram transferidos corretamente.
Por assegurar que um nó envia o token imediatamente, com ou sem dados, cada nó deveria possuir um compartilhamento atribuído da largura de banda. No pior caso, tempo entre transmissões pode ser calculado por 10 adição do tempo para transmitir a unidade de transmissão máxima (MTU) com o tempo de retorno (turn-around) e multiplicando o resultado pelo número de nós, assumindo que todos os nós sobre o £>us estão transmitindo dados e que os dados são do máximo comprimento permitido sobre o bus.
15
BREVE DESCRIÇÃO DOS DESENHOS DA PRESENTE INVENÇÃO
A presente invenção irá ser descrita em maiores detalhes posteriormente com referência para os Desenhos das Figuras acompanhantes, para o propósito de exemplificação, que mostram concretizações da presente invenção. Nos Desenhos:
25
30
A Figura 1
A Figura 2
A Figrura 3
A Figura 4
A Figura 5
A Figura 6
A Figura 7
ilustra uma máquina de estado de protocolo.
ilustra esquematicamente um header de pacote.
ilustra identificadores de protocolo de payload.
ilustra identificadores de comando, ilustra uma requisição de janela de resposta.
ilustra uma resposta de janela de resposta.
ilustra um pacote de tabela de seqüência.
A Figura 8 ilustra um pacote de 'token somente'.
A Figura 9 ilustra um pacote de 'token & dados'.
A Figura 10 ilustra o sistema de token bus em operação.
As Figuras são somente representações esquemáticas e a presente invenção não está limitada para as concretizações nelas representadas.
DESCRIÇÃO DETALHADA DA PRESENTE INVENÇÃO
A seguir é apresentada uma descrição detalhada por intermédio de exemplo de um sistema de token bus em concordância com a presente invenção. É intencionado se conformar neste exemplo para a regulamentação ANSI/IEEE Standard 802.4. É empregado um protocolo de link de dados (protocolo de Layer 2) para a transferência de pacotes se conformando para um protocolo de transmissão (Layer 3) que é preferivelmente IP (Internet Protocol - Protocolo de Internet) entre nós sobre uma metade duplex (half-duplex), rede de multi-drop. É intencionado que o protocolo devesse ter capacidade de ser independente da média física (Layer 1) e ter capacidade de várias diferentes taxas de dados. 0 protocolo irá, entretanto, necessitar conhecer a taxa de bit para estabelecer intervalos de time-out (parada).
Um protocolo de token bus preferido proporciona topologia de bus lógica e arbitração de bus e proporciona tempos de acesso de determinismo para cada nó. Ele pode carregar pacotes de IP (Internet Protocol - Protocolo de Internet) e de ARP (Address Resolution Protocol - Protocolo de Resolução de Endereço) . Um nó pode iniciar o bus sem qualquer conhecimento de outros nós. Preferivelmente também, o sistema pode detectar um novo nó desejando unir o bus e continuar, detectar que um nó deixou o bus e continuar, e ter capacidade de continuar se o nó de token mas ter deixa o bus.
No sistema descrito, um nó pode estar em qualquer um dos seis estados, como mostrado na Figura I. Os estados são 5 um estado Inicial (Inicial state) (10), um estado de Detecção de Nó Master (Master Node Detect state) (11), um estado de Convite de Espera Escravo (Slave Waiting Invite state) (12), um estado de Corrida Master (Master Run state) (13), um estado de Corrida Escravo (Slave Run state) (14), 10 e um estado de Corrida Master Secundário (Secundary Master Run state) (15) .
A Figura 1 mostra, por simplicidade, somente transições à frente. A partir de qualquer dos estados mostrados, um nó pode reverter para o estado Inicial.
15
Estado Inicial (Inicial State)
O estado Inicial (10) é o estado no qual um nó adentra tanto sobre força ativada (power-up) ou quanto como um resultado de detecção de uma falha de bus.
No estado Inicial, o nó presta atenção para tráfego
sobre o bus para um intervalo máximo iinitiai■ O intervalo pode, por exemplo, ser definido pelo endereço MAC único do nó. Por conseqüência, cada nó deveria esperar por um tempo único. Se o nó detecta algum tráfego sobre a linha, ele se 25 movimenta para o estado de Convite de Espera de Escravo. Se nenhum tráfego é detectado, o nó adentra o estado de Detecção de Nó Master.
Estado de Detecção de Nó Master (Master Node Detect State)
No de Detecção de Nó Master (11), um nó assume o papel de "master" do sistema. Ele agora necessita detectar todos os outros nós e começar transmitindo convites imediatamente para bloquear outros nós de virem a assumir o estado de Detecção de Nó Master.
0 processo de convite de nós escravos para unir o bus necessita ser robusto (para capturar todos os nós) e rápido (para possibilitar que o bus venha a iniciar tão rapidamente quanto possível). Durante o processo de detecção de nó, o master irá construir uma Tabela de Seqüência (Seguence Table) (a ser descrita). Esta tabela é uma lista dos endereços de MAC dos nós com o nó 'master' no topo.
Um campo de endereço de 8-bit possibilita potenciais 256 possíveis endereços. Endereço '0' pode ser reservado e endereço '255' pode ser o endereço de transmissão.
0 nó master corrente tem que buscar para cada nó sobre o bus para construir a Tabela de Seqüência. Para minimizar o tempo de partida e para auxiliar a subseqüente detecção de novos nós, uma técnica de busca recursiva pode ser utilizada, geralmente em concordância com a regulamentação ANSI/IEEE Standard 802.4.
O nó master transmite um pacote de requisição de 'janela de resposta' (50) (Figura 5) convidando todos os nós com endereços na faixa a partir de '1' até '254' para responder. Todos os nós no estado de Convite de Espera de Escravo (12) e naquela faixa de endereço tem que responder. Se existir somente um nó naquela faixa, o nó master irá ver a resposta não corrompida e adicionar o nó para a Tabela de Seqüência. Se mais do que um nó responde para a transmissão, o nó Master irá receber uma resposta corrompida. Duas novas faixas são após isso buscadas, a partir de '1' até '127' e a partir de '128' até '254'. O nó master recursivamente busca faixas de endereço de redução contínua até que ele detecta um nó único na faixa (identificado por uma resposta não corrompida) ou ele detecta nenhuns nós em uma faixa (identificado por não ter existido nenhuma resposta para a transmissão). Por exemplo, assume-se que aqueles nós com endereços '2', '4', '5', '10', '53', '126' e '254' estão sobre o bus. Inicialmente, o nó com endereço '2' irá assumir status master e se movimentar para o estado de Detecção de Nó Master (11) . Ele irá após isso começar a criação da Tabela de Seqüência por inserção de seu próprio endereço, '2', no topo.
0 master irá transmitir uma requisição de janela de resposta para a faixa de Ί' até '254'. Os outros nós irão se movimentar para o estado de Convite de Espera de Escravo (12) sobre recepção da transmissão e cada um irá transmitir para o nó master uma resposta indicando que ele está presente. Uma transmissão simultânea pelos nós irá ser recebida pelo nó master como um pacote corrompido. 0 master determina que existe mais do que um nó sobre o bus naquela faixa e divide a faixa inicial em duas sub-faixas, isto é, Ί' até '127' e '128' até '254'. Ele irá transmitir um pacote de requisição de janela de resposta (Figura 5) sobre cada uma destas faixas por sua vez. Se ele recebe um pacote de resposta válido (Figura 6) a partir de um nó único, ele adiciona o nó para a Tabela de Seqüência e não subdivide a faixa de busca adicionalmente. Se ele não recebe nenhuma resposta, depois de tneniiuina_resposta, ele assume que não existe nenhuns nós naquela faixa e não subdivide adicionalmente. Se ele recebe uma resposta corrompida, ele irá subdividir a faixa de busca adicionalmente até que todos os nós venham a ser localizados.
Tabela 1:
Ver Tabela 1 na próxima página 8/30. Tabela I:
Operação Resultado Faixa de Tentativa 1 até 254 Ruim Faixa de Tentativa 1 até 127 Ruim Faixa de Tentativa 1 até 64 Ruim Faixa de Tentativa 1 até 16 Ruim Faixa de Tentativa 1 até 8 Ruim Faixa de Tentativa 1 até 4 Descoberto '5' Faixa de Tentativa 5 até 8 Descoberto '10' Faixa de Tentativa 9 até 16 Descoberto '10' Faixa de Tentativa 17 até 32 Nada Faixa de Tentativa 33 até 64 Descoberto '53' Faixa de Tentativa 64 até 127 Descoberto '126' Faixa de Tentativa 128 até 254 Descoberto '254' A Tabela 1 anteriormente mostra uma simulação da busca 5 de nó master para os outros nós. A Tabela 1 mostra as transmissões de faixas seguidas por qual tipo de resposta o nó master recebeu. A expressão "Ruim" significa que mais do que um nó respondeu; a expressão "Descoberto" significa que uma resposta de nó único foi recebida; a expressão "Nada" 10 significa que nenhuma resposta foi recebida.
A busca mostrou por intermédio de exemplo ter descoberto nós numerados '4', '5', 'IO7, '53', '126' e '254'; seis nós foram descobertos em 13 transmissões.
Um algoritmo exemplificativo para este propósito, expressado em 'C', é mostrado, com anotações, na Tabela 2. A função de busca é chamada externamente com a faixa de '1' até '254'. Tabela 2: void Search (int Min, int Max)
{
int result = BroadCastSearch (Min, Máx); //search range
int newMin; int newMax;
if ((result != NOTHING) && (result != BAD)) //Ifunique node found {
cout« " Found " setw(3) « setfill ('') « result endl; SeqAddNode (result); //Add H
}
else if (result = = BAD) //if multiple nodes
{
cout« " Bad" « endl;
newMax = (Min + ((Max - Min) / 2);
Search (newMin, Max)); //search the Iow half
newMax = (Min - ((Max - Min) / 2);
Search (newMin, Max)); //search the high half
}
else cout «" Nothing"« endl;
}
A função BroadCastSearchO é esperada criar o pacote de transmissão, para transmitir o mesmo sobre o bus e esperar por resposta ou intervalo (time-out). A função retorna tanto o número de nó, se descoberto, 'nada' definido como um número único fora da faixa de endereço válida ou quanto 'ruim', novamente definido como um número único fora da faixa de endereço válida.
Tendo detectado cada nó sobre o bus e adicionado todos eles para a Tabela de Seqüência, o master transmite um pacote (70) (Figura 7) contendo a Tabela de Seqüência para todos os nós. 0 master após isso assume possessão do token e se movimenta para o estado de Corrida Master {Master Run State) .
Se nenhum nó responde para a requisição de janela de resposta inicial, o master irá reverter para o estado Inicial.
Pode ser possível que mais do que um nó pudesse responder para o pacote de requisição de janela de resposta a partir do master e que o tempo de decurso daquelas respostas significasse que elas foram recebidas sem erro. Se os pacotes são recebidos corretamente, o master pode adicionar todos aqueles nós para a Tabela de Seqüência e interromper dividindo na faixa de endereço. Se quaisquer dos pacotes são recebidos corrompidos, o master tem que subdividir a faixa de endereço.
Masters Múltiplos sobre o Bus
É possível que mais do que um nó pudesse adentrar o Estado de Detecção de Nó Master, devido para o fato de que os nós são iniciados fora de sincronismo e cada um determina que este nó deveria ser 'master' no mesmo momento. O bus tem que se recuperar a partir deste estado contencioso.
Quando mais do que um nó transmite um pacote de requisição de janela de resposta, pode existir uma mistura de pacotes bem sucedidos e mal sucedidos. Isto irá resultar tanto em:
(a) nenhum master possuindo um nó sobre sua Tabela de Seqüência;
(b) um master possuindo nós sobre sua Tabela de Seqüência; ou
(c) masters múltiplos possuindo alguns nós sobre suas Tabelas de Seqüência. Se nenhum master possui um nó em sua Tabela de Seqüência, cada master irá retornar para o estado Inicial. Isto irá provocar uma re-sincronização de nós tal que subseqüente re-início deveria ser bem sucedido.
Se somente um master possui um nó ou nós sobre sua Tabela de Seqüência, existe sucesso parcial em iniciação do bus. Aqueles masters sem nenhuns nós em suas Tabelas de Seqüência irão reverter para o estado Inicial e podem se unir para o bus posteriormente como escravos durante uma nova fase de detecção de nó.
Se mais do que um master possui um nó sobre sua Tabela de Seqüência, cada master irá transmitir sua Tabela de Seqüência e tentar começar passagem de token. Muitas colisões de bus irão ocorrer tal que nenhuns escravos recebem a Tabela de Seqüência corretamente ou se alguns assim fizerem, eles irão receber tokens corrompidos. Em um ou em outro evento, o master irá começar a remover escravos a partir da Tabela de Seqüência utilizando Detecção de Perda de Nó (Node Loss Detection) e eventualmente não irá possuir nenhuns nós em sua Tabela de Seqüência. Isto irá provocar que ele venha a reverter para o estado Inicial. Todos os masters irão reverter para o estado Inicial ou, possivelmente, um pode se suceder como master.
Estado de Convite de Espera Escravo (Slave Waiting Invite State)
No estado de Convite de Espera Escravo (12), um nó irá prestar atenção para um convite para unir o bus. Ele irá esperar receber transmissões de requisição de janela de resposta e transmissões de Tabela de Seqüência (70).
Se uma requisição de janela de resposta (50) é recebida, o nó irá olhar na faixa de endereço. Se seu endereço MAC está dentro da faixa ele irá responder por envio de uma Resposta de Janela de Resposta (ResponseWindow Response) (60) (Figura 6) para o master.
Se uma Tabela de Seqüência é recebida, o nó irá determinar onde ele está localizado na Tabela de Seqüência e o endereço do nó abaixo dele na tabela. Este é o endereço para o qual este nó irá sempre passar o token. A tabela é cíclica; se o nó está na parte de baixo (no fundo) da tabela, o nó irá passar o token para o endereço no topo da tabela (o Master) . Se o nó é o segundo nó na tabela, o nó se movimenta para o estado de Corrida Master Secundário (Secundary Master Run state) . De outro modo, o nó se movimenta para o estado de Corrida Escravo (Slave Run state) (14).
Se o nó detecta silêncio sobre o bus por mais do que tSiiêncio_escravo após isso ele irá reverter para o Estado Inicial.
Estado de Corrida Escravo (Slave Run State)
No estado de Corrida Escravo (Slave Run state) (14), o nó irá responder somente para os comandos de Token Somente (Token Only), Token & Dados (Token & Data) e Tabela de Seqüência (Sequence Table) na (Figura 4).
0 nó detecta se existiu silêncio sobre o bus por mais do que tSiiêncio_escravo· Se isto for assim, o nó irá reverter para o estado Inicial (10).
0 nó detecta se ele não recebe o token por mais do que circuitos de ContadorfaIha (countfan) do token em torno do bus. Se isto for assim, o nó irá reverter para o estado Inicial.
Se o nó recebe uma requisição de janela de resposta enquanto ele está neste estado (14), ele ignora aquela requisição. Pode ser assumido que tal uma requisição ocorre porque devido para o fato de que o master está desempenhando Detecção de Novo Nó (New Node Deteetion) . Se o nó recebe um pacote de Token Somente (Only Token), ele tem que transmitir imediatamente tanto um pacote de Token Somente ou quanto um pacote de Token & Dados (se ele possui dados para transmitir).
Se o nó recebe uma Tabela de Seqüência, ele irá sobrescrever sua Tabela de Seqüência corrente e novamente determinar sua localização para estabelecer o endereço de nó de onde passar o token e se seu endereço é o segundo na tabela. Se seu endereço é o segundo na tabela, o nó se movimenta para o estado de Corrida Master Secundário (Secundary Master Run state) . Se o nó descobre que ele não está na Tabela de Seqüência, o nó irá reverter para o estado Inicial.
Estado de Corrida Master (Master Run State)
No estado de Corrida Master (Master Run state) (13), se o nó tem possessão do token ele imediatamente passa sobre o token para o nó abaixo dele na Tabela de Seqüência tanto por transmissão de um pacote de Token Somente, se ele não possui nenhum dado para enviar, ou quanto um pacote Dados e Token se ele possui dados para enviar. Adicionalmente, o master desempenha funções de Detecção de Perda de Nó (Node Loss Detection) e de Detecção de Novo Nó (New Node Detection) como descrito posteriormente.
Detecção de Perda de Nó (Node Loss Detection)
0 nó master também presta atenção para todos os outros tráfegos de bus para detectar a perda do token tanto por corrupção de token ou quanto por um nó deixando o bus. 0 master armazena o último Destino de Token (Destination Token) que foi transmitido sobre o bus. Ele tem que também prestar atenção para silêncio sobre o bus por maior do que
^silêncio·
Se o bus está silencioso por mais do que tsüênoio/ o master deveria assumir que o nó suposto para receber o token no último pacote não recebeu o token corretamente. 0 master incrementa um contador de "queda de token" associado com aquele nó. 0 master irá olhar a Tabela de Seqüência e enviar um pacote de Token Somente (Only Token) para o próximo nó subseqüente na Tabela de Seqüência depois do nó que falhou para responder, para reiniciar o bus.
Se o nó Master detecta que ele contou 'quedas de token' de ContadorfaIha {countfau) em uma fileira para um nó específico, ele determina que o nó deixou o bus. Ele atualiza a Tabela de Seqüência, removendo aquele nó a partir da Tabela de Seqüência e transmite a nova tabela para todos os nós. Ele assume possessão do token e reinicia o bus por passagem do token sobre o bus.
Detecção de Novo Nó (.New Node Detection)
No estado de Corrida Master (Master Run state) (13), um nó também desempenha Detecção de Novo Nó (New Node Detection) . Isto é feito a cada tdetecÇão (tdetect) e pode somente ser feito quando o master suporta o token. Isto é conseguido por transmissão de uma requisição de janela de resposta (50) [como feito no estado de Detecção de Nó Master (Master Run state)] sobre a faixa completa de endereços válidos. Nós que estão no estado de Corrida Escravo (Slave Run state) não irão responder para esta requisição, mas um novo nó no estado de Convite de Espera Escravo (Slave Waiting Invite state) irá responder.
Como anteriormente, se um único nó responde, o nó é adicionado para a Tabela de Seqüência e o master atualiza a Tabela de Seqüência e transmite esta para todos os nós. O novo nó, por conseqüência, se une para o bus. O master tem possessão do token e reinicia o bus por passagem do token sobre o bus.
Se nenhuns dos novos nós deseja se unir para o bus, o master não irá detectar nenhuma resposta depois de
tnenhuina_resposta (tno_response) · 0 nÓ master tem pOSSeSSaO do tokeíl
e reinicia o bus por passagem do token sobre o bus.
Se nós múltiplos desejam se unir para o bus, o master irá receber uma resposta corrompida devido para os múltiplos nós transmitindo simultaneamente. 0 master desempenha seu algoritmo de busca para localizar cada novo nó. 0 bus é colocado em inatividade temporária durante este processo. 0 master adiciona cada novo nó para a Tabela de Seqüência e transmite a tabela atualizada para todos os nós depois que todos os nós tenham sido detectados. Os novos nós, por conseqüência, se unem para o bus. O master tem possessão do token e reinicia o bus por passagem do token sobre o bus.
Estado de Corrida Master Secundário (Secundary Master Run State)
0 estado de Corrida Master Secundário (Seeundary Master Run state) (15) mostrado na Figura 1 não é integralmente necessário. Ele pode ser proporcionado para possibilitar que o nó master venha a deixar ou falhar sem desabilitar a integridade de bus. Na ausência de estado de Corrida Master Secundário (15), quando o master deixa o bus, todos os nós no estado de Corrida Escravo (Slave Run state) deveriam reverter para o estado Inicial e o bus deveria reiniciar. Isto pode tomar algum tempo devido para o fato do retorno (back-off) de cada nó quando determinando o novo master. Adicionalmente, o master pode ter simplesmente recebido um pacote corrompido no qual tal master deveria ter descoberto o token. Entretanto, para requerer que a rede venha a reiniciar devido para o fato de um simples erro de bit deveria normalmente ser insatisfatório.
No estado de Corrida Master Secundário (Secundary Master Run state) (15), o nó presta atenção para todo o tráfego de bus para detectar quando o token é passado para o nó master (o endereço no topo da Tabela de Seqüência). Se o último pacote contido no conjunto de Destino de Token (Token Destination set) para o endereço MAC do Master e após isso tempo de tSiiênei0 passa, o Master Secundário deveria assumir possessão do token (ele é o próximo nó subseqüente na Tabela de Seqüência) e incrementa um contador para contar o número de nenhumas respostas em uma fileira pelo master. 0 nó pode transmitir um pacote de 'Token Somente' (80) ou um pacote de 'Token e dados' (90) para possibilitar que o bus venha a continuar.
Se o nó detecta que o master não respondeu tempos de contadorfaiha icountfa±i) em uma fileira, ele assume que o master deixou o bus. Ele irá atualizar sua Tabela de Seqüência, colocando a si mesmo no topo e removendo o master completamente. Ele transmite a nova Tabela de Seqüência para todos os outros nós no bus. 0 nó após isso se movimenta para o estado de Corrida Master (Master Run state) .
Tempos em Intervalo e Contadores (Timeout Times and Counters)
0 protocolo preferido identifica os seguintes períodos de tempo: (i) tinmai = MAC address * (m * 1 bit time * 10)
(ii) Wcf = ti seconds
(iii) We = n + (2 * MTU * 1 bit time * 10),
(iv) tstence_siaw = j + (2 * MTU * 1 bit time * 10), tsilence__slave > tsilence).
(v) W. WSponse ” (K* Ibittime *10).
O protocolo identifica o seguinte contador: contadorfaiha (countfau) = 3.
Valores possíveis para as 'constantes' mencionadas anteriormente são:
ΙΠ = fcnenhuma_resposta > = 3 0 Se^UndOS, 3 = tal 9U6
tsilênoio_escravo# ^ — 80.
Os valores exatos das constantes mf n, j e K são selecionáveis, mas eles têm que levar em consideração que a codificação de caractere de escape (ver posteriormente) podem aumentar o MTU por um fator de 2.
Codificação de Pacote (Packet Encoding)
Antes da transmissão sobre um meio (mídia) , todos os pacotes são normalmente codificados com caracteres de estilo de escape HDLC para possibilitar um byte de início de frame único a ser utilizado. 0 protocolo de token bus pode utilizar uma versão simplificada desta técnica. Esta forma de codificação proporciona um byte único para o início de um frame.
0 byte de sincronização de frame de inicio de token bus é de 0x5A. Todos os pacotes irão, conseqüentemente, possuir um primeiro byte de 0x5A e este byte não irá aparecer em qualquer outro lugar no meio (na mídia) de transmissão. Se o byte 0x5A acontecer de estar no pacote, ele é convertido para as duas seqüências de byte 0xA5, 0x7A. Para conseguir isto, o caractere de escape 0xA5 é inserido e Mt 5 de 0x5A é segurado para determinar o byte 0x7 A. Se o byte 0xA5 está no pacote, ele é codificado como 5 os bytes 0xA5, 0x85 (novamente, Jbit 5 é segurado no segundo byte) .
Para decodificação, o byte 0x5A irá sempre identificar um início de frame. Se o byte 0xA5 é detectado, ele é retirado (caído) e o byte subseqüente tem seu bit 5
segurado para recriâr o byte original requerido. Assim, se a seqüência de dois bytes 0xA5, 0x7A é lida, ela deveria ser decodificada como o byte único 0x5A. Se a seqüência de dois bytes 0xA5, 0x85 é lida, ela deveria ser decodificada para o byte único 0xA5. Todos os outros bytes em um pacote
são transmitidos como descobertos.
Como um exemplo, se a seqüência de quatorze bytes:
5A:12:34:56:A5:78:90:A5:96:97:98:5A:5B:55:
20
é para ser transmitida, ela é codificada como a seqüência de dezessete bytes:
5A:12:34:56:A5:85:78:90:A5:85:96:97:A5:7A:5B:55:
25
antes de transmissão. 0 receptor irá receber a seqüência anteriormente e decodifica a seqüência de volta para a seqüência de quatorze bytes:
5A:12:34:56:A5:78:90:A5:96:97:98:5A:5B:55:
Tabela 3:
A Tabela 3 posteriormente é um exemplo de um algoritmo para codificação de -um pacote antes de transmissão. Tabela 3:
Typedef struct {
int size
unsigned char data (2*MTU); }t_Packet;
// This takes a raw packet and creates an encoded packet.
// Two separate buffers must be passed, if you pass the // same packet pointer failure will occur.
// Retums size of encoded packet.
Int EncodePacket (t_Packet* raw, t Packet* encoded)
{
encoded->size = 0;
for (int i=0; i<rw->size; i++)
(
if(
((raw->data[i] == 0x5A) && (11=0))// If got 0x5A mid packet
Il //or
(raw->data[i] == 0xA5) // got an 0xA5
)
(
encoded->data(encoded->size) = 0XA5; // Insert esc char encoded->size++; encoded-?data(encoded->size) = raw->data[i]Λ 0x20; // Encode byte.
)
else
(
encoded->data(encoded->size) = raw->data[i];
)
encoded->size++;
)
retum encoded->size;
} Tabela 4:
// This takes an encoded packet and regenerates a raw packet.
// The encoded and raw buffers should be separate.
// Retums the size of the regenerated raw packet.
Int DecodePacket (t_Packet* encoded, t_Packet* raw)
{
raw->size = 0;
for (int i=0; i<encoded-> size; i++ )
(
if (encoded->data[i] == 0xA5) // Found escape char
(
i++; // jump to next byte
// decode the byte and copy to
raw
raw->data[raw->size] = encoded->data[i]A 0x20;
)
else
(
raw->data[raw->size] = encoded->data[i]; // Otherwise just copy.
)
raw->size++;
)
retum raw->size ;
Construindo um Pacote (Building a Packet)
Um pacote é construído preferivelmente na seguinte ordem:
1. Adição do payload (por exemplo, payload de IP) para o header, ajuste no header (Figura 2) do parâmetro de comprimento de dados (bytes 8 & 9) , parâmetros de endereço (bytes 2, 3 e 4) , número de comando (byte 1) e parâmetro de tipo de protocolo (byte 5).
2. Ajuste do parâmetro de soma de verificação (checksum) para zero, cálculo da soma de verificação do header único e ajuste da soma de verificação (Figura 2, bytes 6 & 7) para este valor. 3. Desempenho da codificação de caractere de escape da integridade de pacote para assegurar que existe somente uma instância do byte de sincronização no pacote.
4. Transmissão do pacote sobre a linha.
Compressão de Header de TCP/IP (TCP/IP Header Compression)
0 protocolo de token bus pode ser adaptado para, por exemplo, compressão de header de TCP/IP de Vanl Jacobson. 0 token bus pode ser estendido para aprovisionar para esta compressão por extensão dos códigos de 'campo de protocolo' para identificar se o payload contém headers de TCP/IP comprimidos. Isto irá possibilitar para que pacotes não comprimidos e comprimidos venham a coexistir sobre a mesma rede.
Embora o header contenha campos que não são sempre requeridos [por exemplo, Protocolo, Comprimento de Dados, Destino de Dados em um pacote de Token Somente (Protocol, Data Lenght, Data Destination em um pacote de Token Only) ] , eles estão sempre presentes. Isto possibilita que o receptor venha a criar uma soma de verificação (checksum) do header sem necessidade de conhecer o valor de campo de comando (que pode estar corrompido) . Somente se a soma de verificação estiver correta, irá o valor de campo de comando ser assumido para ser válido. 0 campo de Dados pode ser de zero byte em comprimento.
Protocolo de Identificação (Protocol Identification)
0 campo de Protocolo (byte 5) do header de pacote de token bus (20) (Figura 2) identifica o tipo de protocolo (se algum) empregado no payload de dados. A tabela (30) (Figura 3) indica exemplos dos respectivos valores de byte que podem ser utilizados; 0x00 indica 'nenhum protocolo', 0x01 indica 1ARP' e 0x02 indica 1XP'. Comando s (Coinmands)
0 campo de Comando (byte 1) do header de token bus (20) identifica o tipo de pacote. Os vários comandos e suas identificações são mostrados na tabela (40) (Figura 4).
Requisição de Janela de Resposta (Response-Window Request)
Um pacote de requisição de janela de resposta é utilizado, pelo nó master unicamente, para detectar a presença dos outros nós conectados para o bus. Um exemplo é mostrado pelo pacote (50) na (Figura 5).
O campo de Fonte (Source) é o endereço MAC do nó Master transmitindo o pacote. O Destino de Token (Token Destination) é também o endereço MAC de Master para mostrar que ele mantém possessão do token.
0 campo de 'Comprimento de Dados' (Data Lenght) é um pacote de requisição de janela de resposta para proporcionar em campo de faixa de endereço. 0 master espera todos os nós na faixa de endereço de Mínimo Endereço (Min Address) para Máximo Endereço (Max Address), inclusive, para replicar com um pacote de resposta de janela de resposta.
Resposta de Janela de Resposta (Response-Window Response)
Um pacote de resposta de janela de resposta (60), mostrado, por exemplo, na Figura 6, é somente transmitido por um nó escravo no estado de Convite de Espera Escravo (Slave Waiting Invi te state) depois que aqueles nós tenham recebido uma Requisição de Janela de Resposta (ResponseWindow Request) (50) com seu endereço MAC na faixa. 0 pacote de resposta (60) utilizado pelo nó escravo para indicar que ele deseja se unir para o bus. Para um pacote de resposta de janela de resposta, o nó ajusta o campo de Fonte (Source) para seu próprio endereço e os campos de Destino de Dados e Token (Data and Token Destination fields) para aqueles do master que transmitiu a Requisição.
0 campo de Comprimento de Dados (Data Lenght) é dividido em dois campos de endereço de Verificação de Fonte (Source Check). Eles são ambos ajustados para o endereço MAC de escravo.
0 Master verifica que:
(1) Fonte = Verificação de Fonte 1 = Verificação de Fonte 2
(2) Destino de Dados = Destino de Token
Isto é intencionado para auxiliar a localizar endereços de nó único quando uma contensão de bus pode ter ocorrido.
Tabela de Seqüência (Sequence Table)
Um pacote de Tabela de Seqüência (Sequence Table) exemplificativo (70) como mostrado por intermédio de exemplo na Figura 7 é transmitido pelo master para indicar para todos os nós por que motivo passar o token. Em recepção de um pacote de Tabela de Seqüência, um nó tem que eliminar (deletar) sua Tabela de Seqüência corrente e sobrescrever a mesma com aquela uma recebida.
Os dados da Tabela de Seqüência consistem de uma lista de bytes, cada um o endereço de um nó. A tabela é precedida por um campo de soma de verificação adicional que cobre exatamente a si mesmo e os dados da Tabela de Seqüência. A soma de verificação é calculada utilizando o mesmo método como para o algoritmo de header. Se a Tabela de Seqüência é recebida corrompida, um nó escravo é incapacitado para estabelecer que uma nova Tabela de Seqüência foi transmitida. Se o nó escravo foi removido a partir do bus, ele nunca irá receber o token e o nó escravo irá eventualmente se movimentar de volta para o estado Inicial (10) . Se o nó está ainda sobre o bus então ele irá receber o token, mas pode não passar o token para o nó correto. Isto poderia resultar em um ou mais nós sendo deixados fora do bus, que irão eventualmente cair de volta para o estado Inicial devido para a falta do token. Entretanto, se o nó que foi perdido é o nó master, então controle foi perdido. 0 master secundário irá detectar o master desaparecido e irá assumir como nó master. Em assim fazendo, ele transmite uma nova Tabela de Seqüência. Isto deveria reassumir controle e reiniciar o bus. 0 master precedente irá reverter para o estado Inicial e reunir o bus posteriormente (mais tarde).
No pior caso de Tabelas de Seqüência inconsistentes, um nó poderia passar sobre o token e perder tanto o master e quanto o master secundário. Nenhum destes poderia agora tomar comando do bus e pode deixar o bus funcionando (correndo), mas fora de controle. Eventualmente, os nós, no estado de Corrida Escravo, deveriam detectar que não existem nenhumas tentativas de Detecção de Novo Nó a partir do master e deveriam, conseqüentemente, reverter para o Estado Inicial.
Pacote de Token Somente (Token Only Packet)
Um pacote de 'Token Somente' (80) é mostrado na Figura
8. Ele é utilizado para passar o token para o próximo nó subseqüente na Tabela de Seqüência. Não existe nenhuma resposta transmitida para este comando. Um nó irá transmitir este pacote se ele tiver recebido o (ou tomado possessão do) token, mas não possui nenhuns dados de payload para transmitir. Um nó tendo recebido o Token por intermédio de um pacote de 'Token Somente' ou de um pacote de xToken & Dados' tem que passar o Token imediatamente da mesma maneira. A única exceção para isto é quando o nó Master, tendo recebido o token, determina que é tempo para desempenhar Detecção de Novo Nó (New Node Detection).
Token & Dados (Token & Data)
Um pacote de 'Token & dados' (80) como mostrado por intermédio do exemplo na Figura 9, é utilizado para enviar dados a partir de um nó para um outro nó. Em assim fazendo, o nó tem que também passar sobre o token. O token pode ser endereçado para um diferente nó do que aquele um para o qual os dados são enviados, como esquematicamente mostrado na Figura 10. Isto é conseguido pela provisão de campos de Destino de Token e de Destino de Dados (Token Destination e Data Destination) separados. Devido para o fato de que a rede é um bus, todos os nós irão receber o pacote.
0 nó com o endereço de Destino de Token irá assumir possessão do token. O nó com o endereço de Destino de Dados irá tomar os dados e irá passar os dados para seu manipulador (portador) de protocolo maia alto. Todos os outros nós irão descartar o pacote. Os valores de campo de Destino Ttoken e de Destino de Dados podem ser os mesmos, coincidentemente. Não existe nenhuma resposta transmitida para este comando. Não existe nenhuma soma de verificação sobre o payload de dados; é assumido que o payload contém sua própria verificação de erros.
Na Figura 9, os bytes 10, 11 e em seqüência indicam os dados de payload. 0 pacote pode ser um pacote ARP ou IP.
Cálculo de Soma de Verificação (Checksum Calculation)
0 campo de Soma de Verificação (Checksum) para todos os pacotes de token bus utiliza a soma de verificação IP. Isto não é necessariamente a verificação de soma a mais efetiva, mas é rápida para calcular. 0 código mostrado na Tabela 5 posteriormente pode ser utilizado para construir a soma de verificação.
Para ajustar a soma de verificação em um pacote, o
campo de Soma de Verificação tem que ser primeiro ajustado para 0x0000. A resultante soma de verificação sobre a integridade de header de pacote é após isso carregada para o campo de Soma de Verificação.
o
Tabela 5:
uint16 IP_Checksum( uint8* Data, uint16 Length )
{
uint32 checksum = 0L;
uint16 n;
uint16* p; uint16 carnes;
n = Length » 1 ; // divide by 2
p = (uint16*)Data;
while (n - -)
checksum += *p++;
if (Length & 1)
checksum += Swap ( ((uint8)p) ); checksum += * ((uint8*)p); while ((carries=(uint16) (checksum»16)) I= 0)
checksum = ( checksum & OxfffL) +carries;
retum (uint16) (~checksum);
>
15
A largura de banda de um link utilizando o protocolo de token bus é dependente da faixa de bit e do número de nós sobre o bus. Potencialmente, a faixa de bit poderia ser um pouco lenta e o número de nós um pouco maior.
Em um exemplo prático, o bus irá ser utilizado em 60 Kbps com até 6 nós. Isto deveria efetivamente determinar 10 Kbps por nó assumindo que todos os nós estão transmitindo pacotes de tamanho MTU. Se o MTU é de 1.500 bytes, em 10 Kbps ele deveria levar 1,5 segundos para transmitir um pacote deste tamanho, o que deve ser um retardo de tempo excessivamente longo na rede. Se o MTU fosse de 256 bytes o tempo para transmissão deveria ser reduzido para 256 ms, o que é mais aceitável.
É indesejado que todos os nós sobre um bus devessem estar transmitindo pacotes de tamanho MTU todos de uma só vez. Conseqüentemente, uma redução para um MTU de 256 bytes deveria semelhantemente provocar muita fragmentação em roteadores [routers) . Isto poderia ser particularmente ineficiente se protocolos tais como Modbus TCP/IP estão sendo utilizados.
0 MTU do protocolo deveria ser configurável pelo sistema para possibilitar que desempenho viesse a ser otimizado. O MTU o maior de todos deveria ser pelo menos o mesmo como para a Ethernet, isto é, 1.500 bytes.
Embora a presente invenção tenha sido descrita com referência para concretizações específicas, deverá ser observado por aqueles especializados no estado da técnica que a mesma não deve ser considerada como sendo limitada para estas concretizações exemplificativas e vantajosas descritas anteriormente, mas certamente, um número de mudanças, de variações e de modificações adicionais é conceptível sem se afastar do espírito e do escopo da presente invenção que é unicamente limitada pela proteção estabelecida nas reivindicações de patente posteriormente.
Claims (13)
1. Uma rede de comunicação de token bus compreendendo -uma multiplicidade de nós (1 - 6) conectados por um bus em comum, caracterizada pelo fato de que cada nó em comunicação operativa com o bus é organizado para transmitir, quando em possessão de um token e possuindo dados para transmitir, um pacote de ' token & dados' (90) que inclui um payload e um header que especifica um 10 primeiro endereço identificando qual nó é para receber o token e um segundo endereço identificando qual nó é para receber o payload.
2. Um sistema de acordo com a reivindicação 1, caracterizado pelo fato de que cada nó é organizado para transmitir, quando em possessão do token, mas não possuindo dados para transmitir, um pacote de "token somente" (80) sem um payload e um header que especifica um primeiro endereço identificando que nó é para receber o token.
3. Um sistema de acordo com a reivindicação 2, caracterizado pelo fato de que o pacote de "token somente" (80) especifica no local do segundo endereço um endereço identificando nenhum dos nós.
4. Um sistema de acordo com qualquer reivindicação precedente, caracterizado pelo fato de que cada nó em comunicação operativa com o bus recebe pacotes de 'token & dados' (90) e pacotes de 'token somente' (80) e determina se o token e/ou os dados é/são destinado(s) para aquele nó.
5. Um sistema de acordo com qualquer reivindicação precedente, caracterizado pelo fato de que um nó possui um estado master no qual ele determina a identidade de cada um dos nós em conexão operativa com o bus e difunde (transmite) para todos os outros nós uma tabela de seqüência que especifica uma ordem para a recepção do token.
6. Um sistema de acordo com a reivindicação 5, caracterizado pelo fato de que um nó possui um estado de execução no qual, quando o nó está em recepção da tabela de seqüência e recebe o token, transmite o token imediatamente para o próximo nó subseqüente na tabela de seqüência.
7. Um dispositivo de rede para utilização como um nó em uma rede de comunicação de token bus compreendendo uma multiplicidade de nós conectados por um bus comum, caracterizado pelo fato de que o dispositivo de rede é organizado para transmitir, quando em possessão de um token e possuindo dados para transmitir, um pacote de 'token & dados' (90) que inclui um payload e um header (20) que especifica um primeiro endereço identificando que nó é para receber o token e um segundo endereço identificando que nó é para receber o payload.
8. Um dispositivo de rede de acordo com a reivindicação 7, caracterizado pelo fato de que é organizado para transmitir, quando em possessão do token, mas não possuindo nenhum dado para transmitir, um pacote de 'token somente' (80) sem um payload e um header (20) que especifica um primeiro endereço identificando que nó é para receber o token.
9. Um dispositivo de rede de acordo com a reivindicação 8, caracterizado pelo fato de que o pacote de 'token somente' (80) especifica no lugar do segundo endereço um endereço identificando nenhum dos nós.
10. Um dispositivo de rede de acordo com qualquer das reivindicações 7 até 9, caracterizado pelo fato de que é organizado para receber pacotes de 'token & dados' (90) e pacotes de 'token somente' (80) e para determinar se o token e/ou os dados é/são destinado(s) para aquele dispositivo.
11. Um dispositivo de rede de acordo com qualquer das reivindicações 7 até 10, caracterizado pelo fato de que é operativo para possuir um estado mas ter no qual ele determina a identidade de cada um dos nós em conexão operativa com o bus e difunde (transmite) para todos os outros nós uma tabela de seqüência que especifica uma ordem para a recepção do token e em que um nó em resposta para recepção do token transmite o token imediatamente para o próximo nó subseqüente na tabela de seqüência.
12. Um dispositivo de rede de acordo com qualquer das reivindicações 7 até 11, caracterizado pelo fato de que é operativo para possuir pelo menos um estado de execução no qual ele mantém uma tabela de seqüência que especifica uma ordem para a recepção do token e em que o dispositivo enquanto em referido estado de execução e em resposta para recepção do token transmite o token imediatamente para o próximo nó subseqüente na tabela de seqüência.
13. Um método de operação de uma rede de comunicação de token bus compreendendo uma multiplicidade de nós (1 -6) conectados por um e em comunicação operativa com um bus comum, caracterizado pelo fato de que compreende: transmissão a partir de um nó, quando aquele nó está em possessão e possui dados para transmitir, xim pacote de 'token & dados' (90) para todos os outros nós que estão em comunicação operativa com o bus, o pacote de 'token & dados' (90) incluindo um payload e um header (20) que especifica um primeiro endereço identificando que nó é para receber o token e um segundo endereço identificando que modulo é para receber o payload; e transmissão a partir de um nó, quando este nó está em possessão de um token e não possui nenhum dado para transmitir, um pacote de 'token somente' (80) para todos os outros nós que estão em comunicação operativa com o bus, o pacote de ' token somente' (80) estando sem um payload e possuindo um header (20) que especifica um primeiro endereço identificando que nó é para receber o token.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GBGB0706054.4A GB0706054D0 (en) | 2007-03-29 | 2007-03-29 | Token bus communication system |
| GB0706054.4 | 2007-03-29 | ||
| PCT/GB2008/000436 WO2008119922A1 (en) | 2007-03-29 | 2008-02-08 | Token bus communication system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0809501A2 true BRPI0809501A2 (pt) | 2014-09-16 |
Family
ID=38050402
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0809501-9A BRPI0809501A2 (pt) | 2007-03-29 | 2008-02-08 | Sistema de comunicação de token bus |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US8274920B2 (pt) |
| EP (1) | EP2140622B1 (pt) |
| AT (1) | ATE522047T1 (pt) |
| BR (1) | BRPI0809501A2 (pt) |
| GB (1) | GB0706054D0 (pt) |
| MY (1) | MY146529A (pt) |
| WO (1) | WO2008119922A1 (pt) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104115451A (zh) * | 2012-02-27 | 2014-10-22 | 松下电器产业株式会社 | 主机装置、通信系统以及通信方法 |
| US8797884B2 (en) * | 2012-06-27 | 2014-08-05 | Nxp B.V. | Network communication apparatus, system and method |
| GB201212591D0 (en) | 2012-07-16 | 2012-08-29 | Aker Subsea Ltd | Subsea safety system |
| US10402360B2 (en) * | 2016-06-10 | 2019-09-03 | Johnson Controls Technology Company | Building management system with automatic equipment discovery and equipment model distribution |
| US10623204B2 (en) | 2017-06-11 | 2020-04-14 | Syyed Gholam Reza Moazami | Controlling a distributed system |
| WO2021021961A1 (en) | 2019-07-29 | 2021-02-04 | Enphase Energy, Inc. | Protocol for multi-master communication coordination on shared media channel |
| CN112702248A (zh) * | 2020-12-28 | 2021-04-23 | 苏州和欣致远节能科技有限公司 | 一种低速现场总线实现的高效通讯方法 |
| CN113612817B (zh) * | 2021-07-09 | 2023-11-21 | 浙江中控信息产业股份有限公司 | 一种去中心化的数仓智能组网系统及方法 |
| CN121585496B (zh) * | 2026-01-26 | 2026-04-10 | 深圳市今天国际智能机器人有限公司 | 基于tia-485总线的网络数据传输方法及通信设备 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4236245A (en) * | 1979-04-17 | 1980-11-25 | Bell Telephone Laboratories, Incorporated | Ring communication system data packets reusable a variable number of times |
| US5140586A (en) * | 1988-01-26 | 1992-08-18 | E-Systems, Inc. | Token associated data network communications protocol |
| US4949337A (en) * | 1989-01-30 | 1990-08-14 | Honeywell Inc. | Token passing communication network including a node which maintains and transmits a list specifying the order in which the token is passed |
| US5566178A (en) | 1994-12-22 | 1996-10-15 | International Business Machines Corporation | Method and system for improving the performance of a token ring network |
| US7388872B2 (en) * | 2001-04-06 | 2008-06-17 | Montgomery Jr Charles D | Dynamic communication channel allocation method and system |
-
2007
- 2007-03-29 GB GBGB0706054.4A patent/GB0706054D0/en not_active Ceased
-
2008
- 2008-02-08 US US12/593,817 patent/US8274920B2/en not_active Expired - Fee Related
- 2008-02-08 AT AT08709343T patent/ATE522047T1/de not_active IP Right Cessation
- 2008-02-08 BR BRPI0809501-9A patent/BRPI0809501A2/pt not_active IP Right Cessation
- 2008-02-08 EP EP08709343A patent/EP2140622B1/en active Active
- 2008-02-08 WO PCT/GB2008/000436 patent/WO2008119922A1/en not_active Ceased
- 2008-02-08 MY MYPI20093709A patent/MY146529A/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| US8274920B2 (en) | 2012-09-25 |
| GB0706054D0 (en) | 2007-05-09 |
| WO2008119922A1 (en) | 2008-10-09 |
| EP2140622A1 (en) | 2010-01-06 |
| EP2140622B1 (en) | 2011-08-24 |
| MY146529A (en) | 2012-08-15 |
| US20100135310A1 (en) | 2010-06-03 |
| ATE522047T1 (de) | 2011-09-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0809501A2 (pt) | Sistema de comunicação de token bus | |
| CA2027230C (en) | Station-to-station full duplex communication in a communications network | |
| BR112015014861B1 (pt) | Método e dispositivo para a troca de dados entre assinantes | |
| US20160080168A1 (en) | Can fd | |
| US20120076057A1 (en) | Duplex Mismatch Detection | |
| US6741566B1 (en) | Remote management ethernet network and device | |
| EP2528283B1 (en) | Guardian strategy for distributed time-triggered protocols | |
| DK3035605T3 (en) | VARIABLE DATA SPEED CONTROL PROTOCOL | |
| CN104995874B (zh) | 具有协议异常状态的数据传输协议 | |
| EP4072043A1 (en) | Flexible ethernet overhead multiframe receiving method, apparatus, device, and medium | |
| WO2011017997A1 (zh) | 通讯总线控制方法和装置 | |
| WO2006004823A1 (en) | Method and apparatus for detecting support for a protocol defining supplemental headers | |
| JP3351744B2 (ja) | データ伝送システム | |
| CN113396564B (zh) | 串行总线系统的用户站和在串行总线系统中通信的方法 | |
| CN101317167B (zh) | 总线站以及保持总线站同步的系统和方法 | |
| JP4012851B2 (ja) | 情報処理端末、送信権巡回システム、送信権巡回方法、及び送信権獲得プログラム | |
| CN111147514A (zh) | 一种适用于实时以太网会话层的通信帧及设计方法 | |
| JP2004535093A (ja) | Ｌａｒｑヘッダを抜き取り、ｆｃｓを再生成してスリープモード復帰をサポートする機構 | |
| US20250365764A1 (en) | Physical layer collision avoidance (plca) coordinator redundancy | |
| JPS60259035A (ja) | 通信システム | |
| US20080013565A1 (en) | Reverse Polling Algorithm For Shared Resources To Reduce Collisions In A Network | |
| EP1999882A1 (en) | Duplex mismatch detection | |
| CN118921248A (zh) | 串行总线系统的用户站和在串行总线系统中通信的方法 | |
| Micheletti et al. | A Low-Cost Distributed Architecture for Telecommunicaion Systems | |
| NZ715112B2 (en) | Variable data rate control protocol |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] |
Free format text: REFERENTE A 11A ANUIDADE. |
|
| B08K | Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette] |
Free format text: EM VIRTUDE DO ARQUIVAMENTO PUBLICADO NA RPI 2500 DE 04-12-2018 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDO O ARQUIVAMENTO DO PEDIDO DE PATENTE, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013. |