BR112014029314B1

BR112014029314B1 - Método para sincronização de quadros em um sistema de comunicação por satélite e aparelho para sincronização de quadros em um sistema de comunicações por satélite

Info

Publication number: BR112014029314B1
Application number: BR112014029314-7A
Authority: BR
Inventors: Bhaskar Udaya; Anita Yezdi; Roy Satyajit
Original assignee: Hughes Network Systems, Llc
Priority date: 2012-05-23
Filing date: 2013-05-23
Publication date: 2023-02-28
Also published as: BR112014029314A2; WO2013177374A1; US20130315136A1; US20130315137A1; US8897206B2; EP2853043A4; IN2014MN02416A; US8711759B2; US9166675B2; EP2853043B1; US20140254474A1; EP2853043A1

Abstract

SINCRONIZAÇÃO EM UM SISTEMA DE SATÉLITE GEOESTACIONÁRIO. Trata-se de um sistema e método para possibilitar a sincronização de temporização de quadro de rota de entrada sem a ajuda de dados de efemérides de satélite ou laço de retorno de sinal de hub. Ademais, os mesmos possibilitam o rastreio e a compensação do movimento do satélite para possibilitar que múltiplos remotos usem o TDMA nas fre-quências de rota de entrada, enquanto minimiza-se a abertura. As duas técnicas princi-pais propostas são as abordagens com base em consulta e em CLT, que são usadas em combinação para uma solução ideal. Na abordagem com base em CLT, o hub transmite mensagens de retroalimentação de correção de temporização específicas de remoto na rota de saída conforme necessário. Na abordagem com base em consulta, os remotos derivam a temporização dos mesmos com base em uma difusão de estimativa de atraso médio por feixe pelo hub e um atraso local medido específico para cada corrente de rota de saída a partir de um remoto. Um aspecto da invenção usa o método por triangulação para determinar a posição do satélite. Ademais, um aspecto da invenção usa o método de chegada de rajada de hub (...).

Description

ANTECEDENTES

[001] A presente invenção pertence ao campo de comunicação por satélite, em particular, a conjuntos de procedimentos de sincronização de quadro em sistemas baseados em Acesso Múltiplo por Divisão de Tempo (TDMA) para comunicação entre múltiplos remotos e um hub através de um enlace de satélite.

[002] Um satélite geoestacionário é um satélite que orbita a terra que parece, em geral, estar estacionário em relação a qualquer ponto na terra. Conforme será discutido em mais detalhes posteriormente, satélites geoestacionários "derivam" em certa medida em relação a um ponto na Terra. No entanto, em geral, os mesmos permanecem estacionários. Parte das aplicações dos satélites geoestacionários incluem telefone, internet, televisão, rádio e serviços de comunicação. Inúmeros locais remotos (remotos) que se comunicam com um hub central através do satélite com o uso de canais de TDMA. O TDMA permite que múltiplos canais transmitam intermitentemente na mesma frequência, porém com a temporização de sua transmissão disposta de modo que as rajadas não se sobreponham quando as mesmas chegam ao satélite, porém chegam em sequência e, portanto, são recebidas de modo bem sucedido pelo hub.

[003] Em um sistema de comunicação típico, um hub serve uma pluralidade de remotos localizados em um conjunto de feixes direcionados. Isso é adicionalmente explicado com a ajuda de uma Figura 1.

[004] A Figura 1A ilustra um gabarito exemplificativo de quatro feixes direcionados servidos por um hub.

[005] Conforme ilustrado na Figura, um mapa dos Estados Unidos 102 inclui a colocação geográfica de um feixe 104, um feixe 106, um feixe 108, um feixe 110 e um hub 112.

[006] O hub 112 serve uma pluralidade de remotos localizados no feixe 104, no feixe 106, no feixe 108 e no feixe 110 através de um satélite (não é mostrado). O hub 112 e seus remotos são conectados em uma topologia de estrela ao hub 112 no centro da estrela e os remotos nas pontas da estrela. Nesse exemplo somente um hub é mostrado, no entanto, pode haver múltiplos hubs, em que cada um serve seu próprio conjunto de feixes. Em outro exemplo, um hub localizado em um continente pode estar servindo os feixes localizados em outros continentes. A localização de remotos em um feixe é adicionalmente explicada com a ajuda de uma Figura 1B.

[007] A Figura 1B ilustra feixe 104 com um conjunto de remotos.

[008] Conforme ilustrado na Figura, um remoto 114, um remoto 116 e um remoto 118 são localizados dentro do feixe 104, enquanto que um remoto 120 e um remoto 122 são localizados fora do feixe 104. Nesse exemplo, somente o remoto 114, o remoto 116 e o remoto 118 são servidos pelo hub 112 visto que o remoto 120 e o remoto 122 são localizados fora do feixe 104. O remoto 120 e o remoto 122 podem ser servidos por outro hub.

[009] A Figura 2 ilustra uma comunicação entre um hub e os remotos por meio de um satélite.

[010] Conforme ilustrado na Figura, o hub 112 se comunica com o remoto 114, o remoto 116 e o remoto 118 por meio de um satélite 202. O hub 112 e seus remotos são conectados em uma topologia de estrela com o hub 112 no centro da estrela e os remotos nas pontas da estrela. O remoto 114, o remoto 116 e o remoto 118 utilizam TDMA para acessar canais de rota de entrada compartilhados para transmissões através do satélite 202 para o hub 112. Vários remotos compartilham um canal de rota de entrada para se comunicar com hub 112, compartilhando, assim, a largura de banda. Pode haver várias rotas de entrada associadas a uma rota de saída. Conforme ilustrado na Figura, o remoto 114, o remoto 116 e o remoto 118 são alocados em uma frequência f1 e intervalos de tempo t1, t2 e t3 respectivamente em modo TDMA.

[011] Para um dado feixe, o tempo de propagação de um remoto para o hub através do satélite pode variar em vários milissegundos (ms) para diferentes remotos em um feixe. Por exemplo, para o feixe 104, o tempo de propagação para o remoto 114 é d1, para o remoto 116 é d2 e para o remoto 118 é d3, em que d1, d2 e d3 podem ter valores idênticos ou diferentes. Adicionalmente, conforme o satélite 202 se move em sua orbita, o tempo de propagação entre cada um dentre o remoto 114, o remoto 116 e o remoto 118 e o hub 112 por meio do satélite 202 varia continuamente. A mudança no atraso de propagação como um resultado da mudança de posição do satélite é um atraso de deriva.

[012] O TDMA exige que cada remoto transmita suas rajadas de dados para o satélite para retransmitir para o hub de modo que as rajadas comecem em uma janela estreita de tempo, conhecido como a abertura, em um slot especificado de um quadro particular no hub. As variações no atraso de propagação entre os remotos e o hub exigem que cada hub e o remoto executem procedimentos para determinar exatamente quando o remoto deve transmitir uma rajada de dados, de modo que os mesmos cheguem ao hub nos quadros designados nos tempos designados (isto é, na abertura). Isso é explicado abaixo para um quadro de TDMA com a ajuda da Figura 3.

[013] A Figura 3 ilustra um típico quadro de TDMA.

[014] Conforme ilustrado na Figura, um quadro de TDMA 300 inclui um eixo temporal 302, um eixo temporal 304, um slot 306, um slot 308 e um slot 310. Nesse exemplo, o slot 306 é designado ao remoto 114, o slot 308 é designado ao remoto 116 e o slot 310 é designado ao remoto 118. Um período de guarda 312 é designado entre cada slot para permitir cálculo levemente errado de tempo entre cada rajada a fim de evitar colisão no receptor. Na maioria dos casos, uma palavra única (UW) é transmitida no começo de cada rajada para o receptor reconhecer o início de uma rajada (não é mostrada).

[015] O hub 112 difunde para cada remoto um plano de tempo de rajada a fim de designar intervalos de tempo particulares para utiliza no quadro de TDMA 300. O plano de tempo de rajada pode ser fixado, de modo a designar a cada remoto uma porção particular do período de quadro de TDMA total ou o mesmo pode ser dinâmico, por meio de que o intervalo de tempo alocado é ajustado em resposta às necessidades de tráfego de cada remoto.

[016] Dependendo da localização geográfica do remoto em relação ao hub, cada remoto deve transmitir suas rajadas de modo que todas as rajadas que chegam ao hub devam aparecer no lugar correto. Os remotos mais distantes do satélite devem transmitir mais cedo que os remotos mais próximos ao satélite. Referindo-se de volta à Figura 2, o remoto 114 é mais próximo ao hub 112 do que o remoto 118 (d3 > d1), portanto o remoto 118 deve começar a transmitir antes do remoto 114. De modo similar, o remoto 116 é mais próximo que o remoto 114 (d1 > d2), portanto o remoto 114 deve começar a transmitir antes do remoto 116. Isso garantiria que as rajadas do remoto 114, do remoto 116 e do remoto 118 cheguem ao hub 112 na sequência correta nos tempos designados.

[017] Conforme discutido com referência à Figura 3, um quadro de TDMA de rota de entrada 300 que consiste em rajadas do remoto 114, do remoto 116 e do remoto 118 chega ao hub 112 na sequência correta após certo atraso que corresponde ao atraso de propagação entre os remotos e o hub.

[018] Portanto, múltiplos remotos podem se comunicar com o hub por meio de um satélite com uso da mesma frequência de rota de entrada em um sistema baseado em TDMA de modo que não haja colisões. Quando o satélite é estacionário no céu, a distância entre os remotos para o satélite e para o hub é conhecida visto que o satélite não está se movendo. Portanto o atraso de propagação entre os remotos ao hub por meio do satélite é conhecido devido ao fato de que a distância entre os mesmos é fixa. Se um remoto estiver mais próximo ao satélite que um segundo remoto, então o primeiro remoto irá transmitir com um atraso que é um pouco menor que um atraso associado ao segundo remoto. Os diferentes atrasos (com base nas localizações geográficas diferentes dos remotos, respectivamente) garantem que o satélite irá receber as transmissões do primeiro remoto e do remoto nos intervalos de tempo de TDMA corretamente especificados.

[019] Se o satélite estiver se movendo, então a distância entre os remotos e o hub estará constantemente mudando. Nessas situações, a sincronização de quadro de rota de entrada (do remoto para o hub) é essencial para qualquer sistema baseado em TDMA para permitir que múltiplos utilizem uma única frequência de rota de entrada sem colisões.

[020] Em sistemas de comunicação tradicionais, dados efemérides são utilizados para determinar o movimento de satélite, que descreve a trajetória que o satélite está seguindo conforme o mesmo orbita a terra. Consequentemente, dados efemérides são necessários na porta de comunicação.

[021] Outro método conhecido chamado "laço de retorno de sinal de hub" exige que o hub tenha a capacidade de receber seu próprio sinal de transmissão a fim de fornecer ao hub o atraso de viagem de ida e volta de satélite para rastrear o movimento de satélite. Nesse caso, um remoto é colocado no hub. Quando o hub transmite um sinal, o mesmo é ecoado de volta para o remoto que está ao lado do hub. O hub pode determinar, então, o atraso de propagação medindose o atraso entre a transmissão e a recepção do sinal e controla, portanto, a temporização dos remotos. No entanto, em certos sistemas, o hub não é localizado dentro de um feixe direcionado e, portanto, não tem a capacidade de receber o que havia transmitido anteriormente. Nessa situação, o "laço de retorno de sinal de hub" não é aplicável.

[022] O que é necessário é um sistema e um método para fornecer sincronização de quadro de rota de entrada para rastrear e compensar o movimento de satélite para permitir que múltiplos remotos utilizem TDMA nas frequências de rota de entrada.

BREVE SUMÁRIO

[023] A presente invenção fornece um sistema e um método para fornecer sincronização de quadro de rota de entrada para rastrear e compensar o movimento de satélite para permitir que múltiplos remotos utilizem TDMA nas frequências de rota de entrada, ao mesmo tempo em que minimiza a abertura.

[024] De acordo com um aspecto da presente invenção, um hub é fornecido para uso com uma pluralidade de remotos e um satélite. O satélite pode se comunicar de modo bidirecional com um cada dos remotos e o hub. O hub inclui uma porção de comunicação e uma porção de consulta. A porção de comunicação pode se comunicar de modo bidirecional com o satélite. A porção de consulta pode consultar um número N da pluralidade de remotos para obter um valor de deriva para cada remoto consultado, respectivamente. Um valor de deriva é baseado em uma diferença entre uma referência de temporização inicial e uma referência de temporização subsequente como um resultado de uma mudança de posição do satélite.

[025] Vantagens adicionais e recursos inovadores da invenção são apresentados em parte na descrição a seguir e em parte se tornarão aparente para aqueles versados na técnica mediante exame do a seguir ou podem ser aprendidos através da prática da invenção. As vantagens da invenção podem ser realizadas e obtidas por meio das instrumentalidades e combinações particularmente apontadas nas reivindicações anexas.

BREVE SUMÁRIO DOS DESENHOS

[026] Os desenhos anexados, que são incorporados no relatório específico e formam uma parte do mesmo, ilustram uma modalidade exemplificativa da presente invenção e, juntamente com a descrição, servem para explicar os princípios da invenção. Nos desenhos:

[027] A Figura 1A ilustra um gabarito exemplificativo de quatro feixes direcionados servidos por um hub;

[028] A Figura 1B ilustra o feixe 104 com um conjunto de remotos;

[029] A Figura 2 ilustra a comunicação entre um hub e os remotos por meio de um satélite;

[030] A Figura 3 ilustra um quadro de TDMA típico;

[031] A Figura 4 ilustra relação de temporização para uma abordagem de Temporização de Laço Fechado (CLT), de acordo com um aspecto da invenção;

[032] A Figura 5A ilustra uma modalidade exemplificativa de um hub, de acordo com um aspecto da invenção;

[033] A Figura 5B ilustra uma modalidade exemplificativa de um remoto, de acordo com um aspecto da invenção;

[034] A Figura 6 ilustra a relação de temporização entre o hub e o remoto de acordo com um aspecto da invenção;

[035] A Figura 7 ilustra um diagrama de estado para o caso de uma computação de tempo de deslocamento de remoto, TRO, em estado estável, de acordo com um aspecto da invenção;

[036] A Figura 8 ilustra um diagrama de estado para o caso de CLT em estado estável, de acordo com um aspecto da invenção;

[037] A Figura 9 ilustra um diagrama de fluxo de processo de hub à medida que o sistema transita por diferentes estados, de acordo com um aspecto da invenção;

[038] A Figura 10 ilustra um diagrama de fluxo de processo de remoto à medida que o sistema transita por diferentes estados, de acordo com um aspecto da invenção;

[039] A Figura 11 ilustra uma modalidade da variação em tempo de transmissão de SFNP de acordo com um aspecto da invenção;

[040] A Figura 12 ilustra uma modalidade da relação de temporização entre o remoto e o hub com compensação por atraso em transmissão de SFNP, de acordo com um aspecto da invenção;

[041] A Figura 13 ilustra uma modalidade de medição de atraso local de SFNP de acordo com um aspecto da invenção;

[042] A Figura 14 ilustra uma modalidade do processo de consulta no hub de acordo com um aspecto da invenção;

[043] A Figura 15 ilustra as interações entre o hub e os remotos à medida que o sistema transita de estado de reamostragem para estável, de acordo com um aspecto da invenção;

[044] A Figura 16 ilustra uma modalidade exemplificativa da invenção para calcular as coordenadas de satélite com o uso de triangulação;

[045] A Figura 17 ilustra uma modalidade exemplificativa de um hub que utiliza o método de triangulação de acordo com um aspecto da presente invenção;

[046] A Figura 18 ilustra uma modalidade exemplificativa de um hub para uso em um método de chegada de rajada em hub, de acordo com um aspecto da presente invenção; e

[047] A Figura 19 ilustra a relação de temporização de dois remotos em um feixe em relação ao TRO em uma modalidade exemplificativa.

DESCRIÇÃO DETALHADA

[048] Aspectos da invenção fornecem um sistema e um método para permitir a sincronização de temporização de quadro de rota de entrada sem o auxilio de laço de retorno de sinal de hub ou dados efemérides de satélite. Adicionalmente, os mesmos permitem rastrear e compensar o movimento de satélite para permitir múltiplos remotos a utilizar TDMA na frequência de rota de entradas, ao mesmo tempo em que se minimiza a abertura.

[049] A sincronização de temporização conta com a estimativa de derivar no hub, que fornecida a remotos para calcular sua temporização. Aspectos da invenção fornecem dois conjuntos de procedimentos para sincronização de temporização, que podem ser combinados de diferentes maneiras para um projeto ideal. A primeira abordagem é baseada em CLT, em que hub transmite mensagens de retroalimentação de correção de temporização específica a remoto na rota de saída conforme seja necessário. A segunda abordagem é uma abordagem baseada em consulta, em que os remotos derivam sua temporização com base em uma difusão de estimativa de atraso média por feixe pelo hub e um atraso local medido específico a cada fluxo de rota de saída de um remoto. O hub calcula o atraso médio por feixe com base nas respostas de consulta a partir de alguns remotos selecionados com base nas solicitações de consulta. Tanto abordagens baseadas em CLT quanto abordagens baseadas em consulta serão discutidas em detalhes maiores posteriormente.

[050] Quando um sistema é iniciado, o hub está constantemente tentando constatar se há qualquer remoto ativo na rede. Inicialmente quando o sistema é lançado, não há remotos ativos por certo período de tempo. Isso é conhecido como a "fase de reamostragem”. Visto que não muito tráfego na ausência de múltiplos remotos, um método chamado "aloha na reamostragem" é utilizado, quando os remotos transmitem e o hub recebe de modo que o mesmo permite que a temporização dos remotos esteja errada em um valor grande. Nesse caso, o hub pode tolerar tempo de transmissão extremamente impreciso, na ordem de milissegundos.

[051] Em qualquer sistema, em ordem para um remoto que não recebeu nenhuma alocação de largura de banda para o mesmo entrar no sistema, certo número de canais de contenção está disponível para qualquer remoto. Esses canais são projetados como aloha com slot ou canais aloha. Quando um remoto acorda após ficar ocioso por um longo tempo, o mesmo transmitiria em canais aloha para solicitar largura de banda inicial, que é recebida pelo hub em uma abertura canal grande, ineficiente e ampla. Uma vez que o hub recebe a transmissão através do tal remoto, o mesmo aloca ao remoto sua largura de banda e fornece a correção de temporização inicial. O remoto sairá, então, de canais aloha e utilizará o canal de TDMA regular. Visto que canais aloha são canais de contenção, não há garantia de que somente um remoto estará usando o mesmo em qualquer momento, portanto, existe uma possibilidade de colisão. No entanto, quando a rede é levemente carregada, a probabilidade de colisão é pequena então a transmissão que utiliza canais aloha é aceitável.

[052] Após a alocação de largura de banda inicial, quando o remoto começa a transmitir em um slot de TDMA regular, o mesmo começa a partir da correção de temporização recebida com a solicitação de largura de banda. Devido ao movimento de satélite, após transmitir por certa duração, por exemplo, na ordem de segundos, a temporização irá continuar a derivar visto que os remotos não têm qualquer referência de temporização. O hub está continuamente monitorando o erro com o qual um pacote ou uma rajada está sendo recebida. Quando o hub recebe uma rajada que está próxima demais à borda da abertura ou, em outras palavras, a mesma cruza certo limite de erro, o hub envia uma "mensagem de retroalimentação de temporização de laço fechado" ao remoto que indica que o remoto derivou do centro da abertura em, por exemplo, 'X' microssegundos e solicita que o remoto ajuste sua temporização em 'X' microssegundos. O remoto volta para o centro novamente uma vez que o mesmo receber a "mensagem de retroalimentação de temporização de laço fechado" do hub. A mensagem de retroalimentação entre o remoto e o hub continua sempre que o remoto se distancia do centro da abertura. Isso é chamado mecanismo CLT. Isso é adicionalmente explicado com a ajuda da Figura 4.

[053] A Figura 4 ilustra relação de temporização para abordagem CLT, de acordo com um aspecto da invenção.

[054] Conforme ilustrado na Figura, um quadro de TDMA 400 inclui uma abertura de chegada de rajada 402, uma abertura de chegada de rajada 404 e uma abertura de chegada de rajada 406. Em uma modalidade, a abertura de chegada de rajada 402 corresponde ao remoto 114, a abertura de chegada de rajada 404 corresponde ao remoto 116 e a abertura de chegada de rajada 406 corresponde ao remoto 118.

[055] Uma rajada 408 é transmitida por remoto 114 ao hub 112 por meio do satélite 202 em um canal de rota de entrada. Devido ao movimento de satélite, a rajada 408 é recebida pelo hub 112 após um atraso de deriva de 'X' microssegundo em uma localização 410. Supondo que a rajada 408 seja recebida próximo demais da borda da abertura, o hub 112 envia uma mensagem de retroalimentação de laço fechado ao remoto 114 que indica que o remoto 114 derivou do centro da abertura em 'X' microssegundos e solicita que o remoto 114 ajuste sua temporização em 'X' microssegundos. O remoto 114 volta para o centro novamente, conforme mostrado por uma localização 412, uma vez que o mesmo recebe a "mensagem de retroalimentação de temporização de laço fechado" do hub 112.

[056] CLT é utilizado para corrigir constantemente a temporização de remoto. Se houver múltiplos remotos no feixe, o hub envia as mensagens de correção a cada um dos mesmos conforme necessário.

[057] Quando um novo remoto entra no sistema, o mesmo alcança o foco e salva certo valor de referência de temporização. Uma vez que um certo número de remotos tenha entrado no sistema, isto é, remotos suficientes se tornaram ativos no feixe e salvaram seu valor de referência de temporização, o hub decide começar a abordagem baseada em consulta. O hub envia uma solicitação de consulta a alguns remotos selecionados, por exemplo, remotos aleatoriamente selecionados, e recebe um certo número de respostas de consulta. Com base nas respostas de consulta, o hub computa a estimativa de atraso e difunde a mesma para todos os remotos no feixe. Nesse ponto, o sistema transita para um estado estável, conforme será descrito em mais detalhes abaixo. Em essência, os remotos utilizam essa estimativa de atraso para temporização de sua transmissão ao invés de utilizar retroalimentação de CLT.

[058] O recurso CLT fornece retroalimentação de ajuste de temporização aos remotos, que permite que os remotos transmitam o mais próximo possível do meio da abertura de rajada. No entanto, o CLT não é suficiente em si mesmo visto que o mesmo só pode manter a sincronização após a sincronização inicial ter tido o foco alcançado anteriormente. Os remotos recebem conexões de CLT somente quando os mesmos estão ativos. Após um intervalo ocioso, a sincronização pode ser perdida. Aspectos da invenção fornecem métodos que utilizam abordagens baseadas em CLT e consulta em combinação para uma solução ideal.

[059] Cada hub gerencia a sincronização de temporização de rota de entrada de cada um de seus feixes independentemente dos outros feixes em naquele hub e em outros hubs e feixes. Várias portadoras de rota de entrada podem ser associadas a cada portadora de rota de saída. Em uma modalidade, cada uma dessas portadoras porta vários fluxos de dados de DVB-S2 contínuos (Difusão de Vídeo Digital de Segunda Geração por meio de Satélite) para o satélite para difusão para os remotos no feixe.

[060] Em uma modalidade, um método inovador para sincronização de temporização de quadro, de acordo com um aspecto da invenção, inclui as seguintes ações principais, que serão discutidas em maiores detalhes posteriormente: 1) salvamento das referências de temporização pelos remotos durante o alcance do foco inicial ou um procedimento aloha na reamostragem subsequente, quando o mesmo transita para o estado estável (conforme será descrito em maiores detalhes abaixo); 2) consulta contínua de um pequeno conjunto de remotos pelo hub para obter atrasos de deriva conforme visto pelos remotos; 3) seleção de um subconjunto de respostas de consulta no hub para satisfazer requisições de diversidade geográfica; 4) processamento dos atrasos de deriva em respostas de consulta no hub para computar um valor de atraso de tempo - em uma modalidade exemplificativa, obtêm-se a média dos atrasos de deriva em respostas de consulta no hub para computar um valor de atraso de tempo médio de feixe; 5) anúncio desse valor de tempo médio de feixe pelo hub em um pacote marcado de temporização de superquadro transmitido para todos os remotos no feixe; 6) computação da temporização de quadro no remoto com base no valor médio de feixe anunciado e as referências salvas do remoto; 7) uma fase de interrupção de consulta para administrar casos em que o número de respostas à consulta é insuficiente, com base nas retroalimentações de temporização de laço fechado do hub aos remotos; e 8) uma fase de reamostragem para administrar a inicialização inicial do hub e casos de alternância de hub com base nas retroalimentações de temporização de laço fechado do hub aos remotos.

[061] Uma modalidade exemplificativa de um hub e um remoto é descrito abaixo com a ajuda das Figuras 5A a 5B.

[062] A Figura 5A ilustra uma modalidade exemplificativa de um hub, de acordo com um aspecto da invenção.

[063] Conforme ilustrado na Figura, um hub 502 se comunica com um remoto 504 por meio do satélite 202. O hub 502 inclui adicionalmente uma porção de comunicação 508, uma porção de consulta 510 e uma porção de computação de atraso de deriva 512. Nesse exemplo, a porção de comunicação 508, a porção de consulta 510 e a porção de computação de atraso de deriva 512 são elementos distintos. No entanto, em algumas modalidades, pelo menos duas dentre a porção de comunicação 508, a porção de consulta 510 e a porção de computação de atraso de deriva 512 podem ser combinadas como um elemento unitário. Em outras modalidades, pelo menos uma dentre a porção de comunicação 508, a porção de consulta 510 e a porção de computação de atraso de deriva 512 pode ser implantada como um computador que tem armazenado no mesmo meios legíveis por computador tangíveis para portar ou ter instruções executáveis por computador tangíveis ou estruturas de dados armazenadas nos mesmos. Tais meios legíveis por computador tangíveis podem ser qualquer meio disponível que possa ser acessado por um computador de propósito geral ou de propósito especial. Exemplos não limitantes de meios legíveis por computador tangíveis incluem armazenamento físico e/ou meios de memória tais como RAM, ROM, EEPROM, CD-ROM ou outro armazenamento de disco óptico, armazenamento de disco magnético o outros dispositivos de armazenamento magnético ou qualquer outro meio que pode ser utilizado para portar ou armazenar meios de código de programa desejados na forma de instruções executáveis por computador tangíveis ou estruturas de dados e que possa ser acessado por um computador de propósito geral ou de propósito especial. Quando informações são transferidas ou fornecidas em uma rede ou outra conexão de comunicação (seja com fio, sem fio ou uma combinação dos mesmos) a um computador, o computador vê apropriadamente a conexão como um meio legível por computador. Logo, qualquer conexão é apropriadamente chamada meio legível por computador tangível. Combinações do que foi dito acima também devem ser incluídas no escopo de meios legíveis por computador tangíveis.

[064] O hub 502 é operável para se comunicar de modo bidirecional com o remoto 504 e o satélite 202 por meio de um sinal 506. Por propósitos ilustrativos, o remoto 504 é mostrado na Figura 5A, no entanto, o hub 502 pode ser conectado a uma pluralidade de remotos em um sistema de comunicação típico. A porção de comunicação 508 se comunica de modo bidirecional com a porção de consulta 510 por meio de um sinal 514 e com a porção de computação de atraso de deriva 512 por meio de um sinal 518.

[065] A porção de consulta 510 é operável para gerar solicitações de consulta, que são transmitidas para os remotos. A mesma se comunica de modo bidirecional com a porção de computação de atraso de deriva 512 por meio de um sinal 516.

[066] A porção de computação de atraso de deriva 512 é operável para processar o atraso de deriva com base nas respostas de consulta dos remotos. O hub 502 difunde o atraso de deriva computado para todos os remotos dentro do feixe.

[067] A funcionalidade de diferentes porções do hub 502 será discutida em maiores detalhes posteriormente.

[068] A Figura 5B ilustra uma modalidade exemplificativa de um remoto, de acordo com um aspecto da invenção.

[069] Conforme ilustrado na Figura, o remoto 504 inclui uma porção de comunicação 520, uma porção de consulta 522, uma porção de temporização 524 e uma porção de atraso de deriva 526. Nesse exemplo a porção de comunicação 520, a porção de consulta 522, a porção de temporização 524 e porção de atraso de deriva 526 são elementos distintos. No entanto, em algumas modalidades, pelo menos duas dentre a porção de comunicação 520, a porção de consulta 522, a porção de temporização 524 e a porção de atraso de deriva 526 podem ser combinadas como um elemento unitário. Em outras modalidades, pelo menos uma dentre a porção de comunicação 520, a porção de consulta 522, a porção de temporização 524 e a porção de atraso de deriva 526 pode ser implantada como um computador que tem armazenado no mesmo meios legíveis por computador tangíveis para portar ou ter instruções executáveis por computador tangíveis ou estruturas de dados armazenadas no mesmo.

[070] A porção de comunicação 520 se comunica de modo bidirecional com a porção de consulta 522 por meio de um sinal 528 e a porção de temporização 524 e a porção de atraso de deriva 520 por meio de um sinal 534.

[071] A porção de consulta 522 é operável para transmitir respostas de consulta ao hub 502 em resposta às solicitações de consulta. A mesma se comunica de modo bidirecional com a porção de temporização 524 por meio de um sinal 530.

[072] A porção de temporização 524 é operável para gerar uma referência de temporização em estados de transição de sistema, que é utilizado para gerar atraso de deriva. A mesma se comunica de modo bidirecional com porção de atraso de deriva 526 por meio de um sinal 532.

[073] A porção de atraso de deriva 526 é operável para gerar um atraso valor de deriva, que é transmitido de volta para o hub 502.

[074] A funcionalidade de diferentes porções do remoto 504 será discutida em maiores detalhes posteriormente.

[075] O hub serve como a referência para temporização de quadro de rota de entrada. Os remotos podem manter a sincronização de sua temporização de quadro de rota de entrada com a referência de hub. O hub auxilia os remotos nesse processo fornecendo-se as informações necessárias para manter o número de quadros e sincronização de temporização de quadro.

[076] Em uma modalidade, uma abordagem por feixe é utilizada, quando um único processo de temporização é utilizado para todos os remotos no feixe. Isso implica que uma única entidade no hub pode processar e gerar todas as informações necessárias para manter sincronização. Isso pode ser uma desvantagem a partir de uma perspectiva de implantação, visto que as respostas de consulta recebidas em todas as rotas de entrada têm que ser direcionadas para um único processo de hub, processadas e a estimativa de atraso resultante distribuída para todas as diferentes rotas de saída. A vantagem é que a consulta é conduzida ao longo do maior agrupamento de remotos, o que significa a probabilidade de interrupção de consulta durante períodos de baixa atividade de rede é reduzida. Observe que o método exemplificativo descrito no presente documento segue a abordagem por feixe, no entanto, os aspectos da invenção são igualmente aplicáveis por rota de saída ou outras abordagens com grupos de remoto menores.

[077] A relação de temporização entre o hub e o remoto é mais bem explicada com a ajuda da Figura 6.

[078] A Figura 6 ilustra a relação de temporização entre o hub e o remoto de acordo com um aspecto da invenção. Em uma modalidade, hub é hub 502, o remoto é remoto 504 e satélite é satélite 202.

[079] Conforme ilustrado na Figura, um eixo temporal de rota de entrada 602 é dividido em slots, quadros e superquadros. Um quadro de rota de saída de hub 604 e um quadro de rota de entrada de hub 606 denotam a relação de temporização no local de hub. Um quadro de rota de entrada remoto 608 denota a relação de temporização no local de remoto. Uma duração de quadro de rota de entrada 610 é denotada como TFRM, que, em uma modalidade, é 45 ms. Um intervalo de superquadro 612 é denotado como TSF. Quadro a duração 610 é de modo tal que um superquadro irá conter um número inteiro (M) de quadros. Cada quadro contém um número inteiro de slots (NSL) e cada slot contém um número inteiro de símbolos (NSYM).

[080] Os remotos acessam a rota de entrada transmitindo-se em rajadas, em que cada um dos mesmos ocupa múltiplos slots. Uma palavra única é colocada no começo da rajada a fim de permitir a detecção de rajada no hub. A rajada pode ser detectada somente se o último símbolo da palavra única chegar dentro da abertura.

[081] A fim de cronometrar suas rajadas corretamente, os remotos podem estabelecer uma referência de tempo que é precisamente sincronizada com a referência de tempo do hub e que leva, também, em consideração os atrasos de propagação com variação de tempo. Por exemplo, por si só, a rota de saída de padrão DVB-S2 não tem qualquer marcador de tempo que um remoto possa utilizar para sincronizar sua com referência de tempo hub. Em uma modalidade, cada hub difunde na rota de saída uma referência de temporização, na forma de um Pacote de Numeração de SuperQuadro (SFNP), para todos os remotos no feixe. O SFNP é transmitido pelo hub na rota de saída uma vez a cada TSF. Cada fluxo de DVB-S2 de difusão porta um SFNP separado, que fornece a referência de temporização para os remotos designada para aquele fluxo de DVB-S2 particular. Um SFNP separado para cada fluxo de rota de saída é necessário visto que o atraso local entre os tempos pretendidos e reais de transmissão de SFNP pode ser diferente para diferentes fluxos de rota de saída, que será discutido em maiores detalhes posteriormente.

[082] O SFNPN é o Pacote de Numeração de Superquadro que marca o quadro N. Conforme ilustrado na Figura, diferentes temporizações são denotadas pelo a seguir. THO é um tempo de deslocamento de hub 614, que é o tempo entre a transmissão de SFNPN no hub e o início da recepção do quadro N no hub. Isso também é conhecido como deslocamento de espaço-tempo offset (STO). Um tempo 616 denota a transmissão de SFNPN e um tempo 618 denota a transmissão de SFNPN+16. THS é um hub para o tempo de propagação de satélite 620. TSR é um satélite para o tempo de propagação de remoto 624. TRO é um tempo de deslocamento de remoto 626, que é o tempo entre recebimento "ideal" de SFNPN em um remoto e o tempo de transmissão para o início de transmissão para o quadro N nesse remoto. TRS é um remoto para o tempo de propagação de satélite 628 (mesmo valor que TSR). TSH é um satélite para o tempo de propagação de hub 622.

[083] Observe que: THO = THS + TSR + TRO + TSH (1)

[084] O tempo de ida e volta do hub para o satélite, THS + TSH, pode ser escrito, também, como THSH. Em outras palavras, THSH é atraso de propagação como um resultado de transmissão do hub para o satélite e a transmissão do satélite para o hub. Logo, THO = THSH + TSR + TRO + TRS (2)

[085] Começando no lançamento do sistema, o hub transmite um SFNP a cada milissegundo de TSF em cada fluxo de DVB-S2 de difusão de cada portadora de cada feixe. Um remoto baseia sua temporização de quadro no SFNP recebido no fluxo de DVB-S2 de difusão ao qual o mesmo é designado. Para os propósitos de temporização de rota de entrada, o SFNP contém os seguintes campos: um número de quadro de rota de entrada; um atraso local de SPNP; um THSH-EST; um estado de sistema; um sinalizador de CLT_ON; e o identificação de alternância/reinicialização de hub.

[086] Em relação ao número de quadro rota de entrada N, o tempo de transmissão de SFNP com número de quadro N (SFNPN) serve como um marcador para o início do quadro de rota de entrada de hub N. Na Figura 6, o mesmo é representado pelo tempo 616.

[087] Em relação ao atraso local de SFNP, esse é o atraso entre os tempos pretendidos e ideais de transmissão de SFNP no hub. O atraso de SFNPN-M local é medido no hub e transmitido como parte do SFNPN para permitir que o remoto compense o atraso local na transmissão de SFNPN-M. M é o número de quadros/superquadro.

[088] Em relação ao THSH-EST, isso é utilizado pelos remotos para computar o TRO a fim de tempo rota de entrada rajada transmissões. No estado de reamostragem, esse valor é computado com o uso de coordenadas de hub e supondo-se que o satélite está no centro de sua caixa de manutenção de estação (THSH-NOM), também conhecido como o centro de caixa (CoB). Em estado estável, esse valor é computado com uso das informações contidas em respostas de consulta. No estado de interrupção de consulta, o valor de CoB é utilizado.

[089] Em relação ao estado de sistema, esse é utilizado pelo hub para sinalizar a remotos o estado de hub atual. O mesmo assumir os valores de 0, 1 ou 2, que correspondem ao estado de reamostragem, ao estado estável e ao estado de interrupção de consulta respectivamente. Os remotos monitoram esse campo no SFNP e seguem diferentes procedimentos dependendo de seu valor. Se o mesmo for 0 indicando o estado de reamostragem, os remotos contam com aloha na reamostragem/CLT para temporização. Quando o valor muda de 0 no SFNP anterior para 1 no SFNP atual, uma transição de estado de amostragem para estado estável ocorreu. Os remotos ativos que veem que essa transição salva suas referências. Se o valor desse campo for 1 indicando estado estável, os remotos podem computar TRO com base no THSH-EST ou contam com CLT (dependendo do sinalizador de CLT ATIVADA). Se esse campo for 2, indicando a interrupção de consulta, os remotos contam com aloha na reamostragem/CLT para temporização. No entanto, os remotos ativos não salvam referências quando o hub transita de interrupção de consulta para o estado estável (em contraste com a transição de estado de reamostragem para estado estável).

[090] Em relação ao sinalizador de CLT_ON, esse é utilizado pelo hub para sinalizar a remotos o mecanismo de temporização de rota de entrada que é utilizado no momento. Se esse sinalizador for VERDADEIRO, o sistema está utilizando o mecanismo de CLT e o hub fornece correções de temporização a remotos. Se o mesmo é FALSO, o sistema está dependendo do mecanismo de computação TRO nos remotos. Se um remoto receber uma retroalimentação de CLT enquanto o sinalizador de CLT_ON é FALSO, o mesmo ignora a retroalimentação de CLT.

[091] Em relação à identificação de alternância/reinicialização de hub, esse campo contém informações para permitir que um remoto detecte se algum dos eventos seguintes ocorreu enquanto o mesmo estava ocioso ou desligado: 1) uma alternância do hub no qual o mesmo salvou referências para um hub diferente: ou 2) uma reinicialização do hub no qual o mesmo salvou referências.

[092] Conforme ilustrado na Figura 6, o hub começa o um intervalo de tempo de quadro N de TDMA de rota de entrada, THO, após o mesmo transmitir o SFNPN. O THO pode ser ajustado grande o suficiente de modo que um SFNP possa ser recebido por um remoto que está o mais distante do satélite, fazer com que aquele remoto faça um pouco de processamento, então transmitir uma rajada de dados a tempo de ser recebida de volta no hub no começo do número de quadro dado no pacote de SFNP. Se o THO satisfizer essa condição, significa que um remoto pode receber um pacote de alocação de largura de banda (BAP) e ter tempo para o processamento e a transmissão da rajada na largura de banda alocada no BAP.

[093] Na prática, o instante real de transmissão de SFNP está levemente atrasado do instante pretendido de transmissão de SFNP devido ao processamento de transmissão no hub. Observe que o THO é medido a partir do instante pretendido de transmissão de SFNP. O atraso entre os instantes pretendido e real de transmissão é medido no hub e difundido no próximo SFNP. Os remotos utilizam isso para corrigir esse atraso conforme será discutido em maiores detalhes posteriormente.

[094] Se um remoto transmite no fim de seu intervalo de TRO após receber o SFNPN, o hub receberá a rajada no primeiro slot dentro do quadro N. Se o remoto precisar transmitir em um slot posterior no quadro N (ou em um slot em quadros N+1 - N+M-1), o mesmo adiciona o atraso de tempo para esse slot (e esse quadro) ao fim do intervalo de TRO para determinar o tempo de transmissão.

[095] Temporização de rajada correta exige o conhecimento ou a estimativa do TRO no remoto. Um TRO mais preciso permite o uso de uma abertura menor para receber a rajada no hub. É desejável manter a abertura o menor possível, visto que a abertura se torna uma sobrecarga significativa e reduz a taxa de transferência. No entanto, o tamanho de abertura não pode ser reduzido abaixo de um valor mínimo. Essa limitação é devido aos erros de medição de temporização no hub ou no remoto e à abordagem utilizada para computador TRO. As seguintes considerações podem ser levadas em consideração: a disponibilidade dos dados efemérides de satélite; a precisão de informações de localização de remoto; a deriva de satélite em sua órbita efeméride (caixa de satélite); a distribuição geográfica de remotos; erros de medição de temporização; e a ausência do laço de retorno de hub.

[096] Em relação à disponibilidade dos dados efemérides de satélite, os dados efemérides de satélite não estão disponíveis para os propósitos de temporização de quadro de rota de entrada. Isso significa que o atraso de propagação de hub para satélite 620 (THS) é desconhecido.

[097] Em relação à precisão de informações de localização de remoto, as informações de localização de remoto não são baseados em GPS (Sistema de Posicionamento Global) e são conhecidas somente para a precisão do centro da região de CEP mais próxima. Isso significa que o atraso de propagação de remoto para satélite 624 (TSR) é imprecisa. No entanto, em outras modalidades, as informações de localização GPS podem ser utilizadas para reduzir adicionalmente o tamanho de abertura.

[098] Em relação à deriva de satélite em sua órbita efeméride (caixa de satélite), conforme o satélite se move em sua órbita, THS e TSR mudam continuamente e TRO precisam ser computados novamente para levar em conta essas mudanças.

[099] Em relação à distribuição geográfica de remotos, os raios de feixe são da ordem de centenas de quilômetros (km). Em qualquer dado instante no tempo, os remotos dentro de um feixe podem ter valores de TRO diferentes um do outro.

[100] Em relação aos erros de medição de temporização, aos relógios utilizados no sistema, à temporização de símbolo de rota de saída e rota de entrada, à temporização de transmissão de rajada e medição de chegada de rajada, todos têm erros pequenos, porém finitos, que contribuem para o tamanho da abertura.

[101] Em relação à ausência do laço de retorno hub, os hubs não têm a capacidade de receber suas próprias transmissões de rota de saída. Isso elimina a possibilidade de utilizar medições de atraso de "laço de retorno de hub " no hub para os propósitos de temporização de quadro.

[102] Dadas as restrições acima, o sistema (hub e os remotos) podem empregar procedimentos para estimar TRO em cada remoto o mais precisamente possível. Em um mínimo, a abertura pode ser ampla o suficiente para acomodar o erro de pior cenário total devido aos erros na estimativa de TRO, sincronização de relógio e medições de temporização citadas acima. Outras considerações podem fazer com que seja necessário operar com um tamanho de abertura maior que o valor mínimo (por exemplo, equilibrar a sobrecarga rota de saída devido a mensagens de correção de temporização com a sobrecarga rota de entrada devido ao comprimento de abertura aumentado).

[103] O projeto de temporização de quadro de rota de entrada apresentado de acordo com aspectos da invenção utiliza uma combinação de quatro conjuntos de procedimentos. A seleção de utilizar um conjunto de procedimentos particular dependera dos estados do sistema e do remoto. Os conjuntos de procedimentos utilizados são: 1) a computação de TRO no remoto; 2) as correções de TRO do hub (CLT); 3) Alcance do foco; e 4) Aloha na reamostragem.

[104] Quando o sistema é inicialmente lançado ou se o mesmo estiver em um estado de interrupção, o sistema conta com aloha na reamostragem e retroalimentação de CLT para remotos para manter temporização de rota de entrada. Remotos recentemente instalados utilizam alcance do foco para obter temporização inicial. Quando o sistema está em estado estável, o hub pode ativar ou computação de TRO ou CLT para manter a temporização computando-se uma estimativa de temporização (THSH-EST) de acordo. As transições de estado entre diferentes estados são adicionalmente explicadas com a ajuda da Figura 7 e da Figura 8.

[105] A Figura 7 ilustra um diagrama de estado para o caso de computação de TRO em estado estável, de acordo com um aspecto da invenção.

[106] Conforme ilustrado na Figura, um diagrama de estado 700 inclui um estado de lançamento inicial S702, um estado de reamostragem S704, um estado estável S706, um estado de interrupção de consulta S708 e um estado de recuperação de interrupção de hub S710. Diferentes estados mostram a situação de um campo "Estado de Sistema" em SFNP, um sinalizador "CLT_ON" e o valor de THSH em diferentes cenários. Para os propósitos de temporização, o sistema pode ser considerado estar em um dos estados conforme discutido abaixo.

[107] O sistema está no estado de reamostragem (S704) durante o período de lançamento inicial (S702) ou o mesmo pode transitar para esse estado quando o mesmo estiver se recuperando de um evento de interrupção de hub (S710). O campo de "Estado de Sistema" em SFNP é ajustado para 0 para indicar que o sistema está no estado de reamostragem (S704). O sinalizador de CLT_ON é ajustado para VERDADEIRO para indicar o uso de CLT no estado de reamostragem (S704). Os dois cenários nos quais o sistema está no estado de reamostragem (S704) são discutidos abaixo.

[108] Durante o período de lançamento inicial (S702), o sistema não tem uma população grande o suficiente de remotos para estimar atraso de deriva de satélite, que é necessário para computar a temporização de rajada nos remotos. Em outras palavras, o número de respostas de consulta utilizáveis é menor ou igual a (NMinPollResp + NpollRespHist). Visto que os remotos não têm referências salvas, as respostas contêm valores nominais (THSH-NOM) que não transmitem informações de atraso de deriva. Procedimentos especiais precisam ser utilizados até que um número suficiente de remotos esteja na rede. Subsequentemente, o processo de estimativa de temporização inicia e o sistema transita para o estado estável (S706).

[109] No evento de um hub desabilitado, os remotos são alternados para um hub redundante. Quando o hub redundante estiver ativo, os remotos têm que estabelecer sincronização com aquele hub. No evento de o hub ou um componente de hub (que controla a temporização) ficar inoperante e então reinicia (por exemplo, devido à interrupção de potência), o processo de estimativa de temporização é interrompido, levando a uma perda possível de sincronização entre o hub e os remotos. Nesse caso, não há alternância de hub para um hub redundante, visto que o hub primário recuperou. Em qualquer caso, procedimentos especiais são necessários para estabelecer a sincronização entre o hub e os remotos. Uma vez que o processo de estimativa de temporização tenha reiniciado, o sistema transita para o estado estável (S706).

[110] O procedimento utilizado para a sincronização em ambos os cenários é o mesmo, com base em uma combinação de aloha na reamostragem e CLT. Há uma diferença devido ao fato de que durante recuperação de hub, o número de remotos na rede é muito maior que durante lançamento inicial. Isso significa que o número de remotos competindo pelo número limitado de canais aloha é muito maior que durante a recuperação de hub que durante lançamento inicial. Para impedir um colapso congestivo durante a recuperação de hub, o hub pode anunciar (em SFNP) uma retirada maior para utilizar use com aloha na reamostragem e aumentar temporariamente o número de canais aloha em um valor significativo, até que o sistema alcança o foco do estado estável. Essa é a diferença principal entre os dois cenários.

[111] O sistema transita para o estado estável (S706) quando um número suficiente de remotos é comissionado, tem o foco alcançado e ativo na rota de entrada. Isso significa que nesse estado, em cada tempo de consulta, o hub pode encontrar um conjunto de remotos ativos que podem ser consultados e receber um número mínimo exigido de respostas úteis (NMinPollResp) que podem ser utilizadas para estimar o atraso de deriva. Em uma modalidade, o valor mínimo recomendado para NMinPollResp é 10 e NpollRespHist é 100, as será discutida em maiores detalhes posteriormente. O campo de estado de sistema em SFNP é ajustado para 1 para indicar que o sistema está em estado estável (S706). Além disso, o sinalizador de CLT_ON é ajustado para FALSO nesse estado.

[112] O sistema pode transitar para o estado de interrupção de consulta (S708) somente a partir do estado estável (S706), quando o mesmo não tiver a capacidade de manter a estimativa de temporização devido a um número insuficiente de respostas de consulta. Quando o hub recebe um número insuficiente de respostas para solicitações de consulta, a estimativa de temporização (THSH-EST) não pode ser computada para a precisão exigida para remotos para calcular o tempo de rajadas em uma abertura normal. Quando o número de respostas de consulta tiver aumentado acima de um limite e o processo de temporização tiver se recuperado, o sistema transita de volta para o estado estável (S706). Os limites que controlam a transição entre o estado estável (S706) e os estados de interrupções de consulta (S708) incluem histerese para impedir que o sistema de alteração (isto é, comutação frequente) entre esses estados. O campo de estado de sistema em SFNP é ajustada para 2 para indicar que o sistema está no estado de interrupção de consulta (S708).

[113] Embora o sistema esteja em estado estável, Se houver uma indicação da falha de hub, o sistema transita para o estado de recuperação de interrupção de hub S710. O campo de reinicialização/alternância de hub é ajustado indicando que uma reinicialização/alternância de hub ocorreu enquanto o remoto estava desativado. Nesse caso o sistema se move de volta para o estado de reamostragem (S704) de modo que o remoto salve um novo conjunto de referências com o uso de aloha na reamostragem. Um novo processo de estimativa de THSH é iniciado, que não tem continuidade com o processo de estimativa de THSH no qual o remoto salvou suas referências. Quando o remoto se torna ativo de novo, o mesmo precisa de uma maneira para detectar esse evento e reajustar suas referências com base na nova estimativa d e THSH-EST. Em uma modalidade, esse campo pode ser um carimbo de data/hora que indica o tempo em que a nova inicialização de hub ocorreu. Quando um remoto salva suas referências, o mesmo salva o valor desse campo. Em qualquer tempo, se o mesmo encontrar uma incompatibilidade entre seu valor salvo e o valor anunciado no SFNP, o mesmo declara que uma nova inicialização ocorreu e segue os procedimentos para salvar novas referências conforme será discutido em maiores detalhes posteriormente.

[114] O comportamento de sistema em diferentes estados será discutido em maiores detalhes posteriormente.

[115] As transições de estado para o caso de CLT em estado estável são adicionalmente explicadas com a ajuda da Figura 8.

[116] A Figura 8 ilustra um diagrama de estado para o caso de CLT em estado estável, de acordo com um aspecto da invenção.

[117] Conforme ilustrado em um diagrama de estado 800, um estado estável S802 utiliza CLT para temporização enquanto as transições entre o estado de lançamento inicial S702, o estado de reamostragem S704, o estado de interrupção de consulta S708 e o estado de recuperação de interrupção de hub S710 são as mesmas que no diagrama de estado 700.

[118] Se o campo de CLT_ON em SFNP for VERDADEIRO no estado estável S802, o mecanismo de CLT é utilizado pelo hub para difundir correções para cada remoto para corrigir seus valores de TRO. Cada remoto recebe retroalimentação de temporização do hub para cada rajada aloha (reamostragem ou normal) e retroalimentação de temporização durante tráfego alocado, sempre que o erro de temporização exceder o limite de atraso de deriva de CLT. Isso permite que o remoto corrija seu TRO imediatamente e mantenha sua precisão para rajadas de abertura normais. O mecanismo de CLT de acordo com aspectos da invenção é descrito em detalhes posteriores.

[119] A Figura 9 ilustra um diagrama de fluxo de processo de hub à medida que o sistema transita por diferentes estados, de acordo com um aspecto da invenção.

[120] Conforme ilustrado na Figura, um diagrama de fluxo de processo de hub 900 corresponde ao estado de reamostragem (S704), ao estado estável (S706 ou S802) e ao estado de interrupção de consulta (S708) de diagramas de estado 700 e 800. Para os propósitos de discussão, doravante, o estado de reamostragem será utilizado para o estado (S704), o estado estável será utilizado para o estado (S706 ou S802) e o estado de interrupção de consulta será utilizado para o estado (S708).

[121] Após o lançamento inicial do hub (S902), o sistema move para um processo de configuração (S904), que inclui configurar o campo de "Estado de Sistema" em SFNP para 0 para indicar que o sistema está no estado de reamostragem e o sinalizador de CLT_ON para VERDADEIRO para indicar o uso de CLT no estado de reamostragem. Um valor nominal de THSH (THSH-NOM) é utilizado visto que não há informações de atraso de deriva disponíveis no estado de lançamento. Se o sistema tiver se movido para o estado de reamostragem devido a uma interrupção de hub (S906), anunciar uma retirada de aloha maior de modo a não sobrecarregar a capacidade de aloha disponível no caso de um número maior de remotos estiver presente na rede na interrupção de hub.

[122] Em um processo de transmissão (S908), o hub transmite o SFNP e as solicitações de consulta. Uma retroalimentação de CLT e um procedimento aloha na reamostragem são utilizados para temporização de rota de entrada. Um remoto recentemente instalado segue procedimentos de alcance do foco para determinar seu TRO. O hub transmite mensagens de retroalimentação de correção de temporização específica a remoto (TRO) na rota de saída.

[123] Em um processo de monitoramento (S910), o hub monitora as respostas de consulta recebidas dos remotos. Se o número de respostas de consulta exceder um mínimo (NMinPollResp + NpollRespHist), o sistema transita para o estado estável. Se as respostas de consulta não forem o suficiente, o sistema fica no estado de reamostragem.

[124] No estado estável, um processo de configuração (S912) inclui configurar o campo de "Estado de Sistema" no SFNP para 1, o sinalizador de CLT_ON para VERDADEIRO se a CLT for utilizada ou para FALSO se a CLT não for utilizada. O THSH em SFNP é baseado no THSH-EST computado a partir das respostas de consulta.

[125] Em um processo de transmissão (S914), o hub transmite o SFNP e as solicitações de consulta. Os remotos recentemente instalados utilizam alcance do foco para obter a sincronização de temporização de rota de entrada inicial. O hub computa um THSH-EST baseado nos atrasos de deriva recebidos da consulta.

[126] Se o sinalizador de CLT_ON for VERDADEIRO (S916), o hub fornece retroalimentação de correção de TRO de CLT (S918) a remotos. Se o sinalizador de CLT_ON for FALSO, a correção de TRO é baseada no THSH-EST.

[127] Se o número de respostas de consulta (S920) exceder um mínimo (NMinPollResp + NpollRespHist), o hub computa THSH-EST com base nas respostas de consulta (S922), que é transmitido para os remotos no SFNP. Se as respostas de consulta não forem o suficiente, o sistema transita para o estado de interrupção de consulta.

[128] No estado de interrupção de consulta, um processo de configuração (S912) inclui configurar o campo de "Estado de sistema" em SFNP para 2, o sinalizador de CLT_ON para VERDADEIRO e THSH em SFNP é baseado no valor de THSH-EST de estado estável mais recente.

[129] Em um processo de transmissão (S926), o hub transmite o SFNP e as solicitações de consulta. Os remotos recentemente instalados utilizam alcance do foco para obter sincronização de temporização de rota de entrada inicial. O hub computa um THSH-EST com base no valor de THSH-EST mais recentemente computado quando o sistema esteve pela última vez no estado estável. O sistema reverte para CLT e aloha na reamostragem para temporização de rota de entrada e as correções de TRO de aloha na reamostragem e correções de TRO de CLT são realizadas.

[130] Se o número de respostas de consulta (S928) exceder um mínimo (NMinPollResp + NpollRespHist), o sistema volta para o estado estável. Se as respostas de consulta não forem o suficiente, o sistema continua no estado de interrupção de consulta.

[131] O comportamento de remoto à medida que o sistema transita por diferentes estados é discutido abaixo com a ajuda da Figura 10

[132] A Figura 10 ilustra um diagrama de fluxo de processo de remoto à medida que o sistema transita por diferentes estados, de acordo com um aspecto da invenção.

[133] Conforme ilustrado no diagrama, um fluxo de processo de remoto 1000 corresponde ao hub em estado de reamostragem, o hub em estado estável e o hub em estado de interrupção de consulta de diagramas de estado 700 e 800.

[134] Um remoto recentemente instalado pode passar por um procedimento de alcance do foco para adquirir informações de temporização para entrar na rede (S1002). Um remoto é considerado "ativo" em qualquer tempo se o mesmo tiver atualmente solicitações de largura de banda pendentes ou se o mesmo estiver transmitindo. Tal remoto pode ser selecionado para consulta pelo hub e se for, o mesmo responde às solicitações de consulta. Se um remoto não tiver alocações ou solicitações de largura de banda (isto é, não estiver transmitindo), porém não estiver desativado, o mesmo é considerado um remoto "ocioso". Tal remoto tem a capacidade de receber a rota de saída e pode receber solicitações de consulta. Se não mais que segundos de TOCIOSO tiverem passado desde a última correção (S1004), um remoto ocioso pode utilizar seu valor de TRO previamente corrigido (S1006) para transmitir sua próxima rajada. Se o período ocioso for mais que segundos TOCIOSO, o procedimento Aloha na reamostragem é utilizado para rajada iniciada e um novo valor de TRO é recebido (S1008). Se CLT estiver sendo utilizado, um remoto ocioso pode utilizar seu valor de TRO previamente corrigido (S1006) para transmitir sua próxima rajada (S1010). Depois daquele tempo, o mesmo perde sincronização e pode sincronizar novamente antes que o mesmo puder transmitir novamente (S1012). Se consultado, um remoto ocioso fornece respostas de consulta em canais de contenção. Finalmente, um remoto pode ser "desligado”, no caso de o mesmo não poder se comunicar na rede (S1014).

[135] Se o remoto estiver ativo no tempo de transição (S1016) a partir da reamostragem ou do estado de interrupção de consulta ao estado estável, o remoto salva referência (S1018) na transição. Um remoto recentemente instalado passa por um procedimento de alcance do foco para adquirir informações de temporização para entrar na rede (S1026). Se o sistema estiver em estado estável no tempo de alcance do foco, os valores de temporização obtidos durante o alcance do foco são salvos como referências e utilizados para rajadas de temporização na rota de entrada (S1028). Se o remoto estava ocioso ou desligado no momento de transição, o procedimento Aloha na reamostragem é utilizado para rajada inicial e um novo valor de TRO é recebido (S1020). Nesse caso, o remoto salva seu novo valor de TRO e o valor atual de THSH-EST no SFNP como referências (S1022).

[136] Uma vez que o remoto tenha salvado referências de temporização, a resposta de consulta sinalizador é ajustada para VERDADEIRO (S1024) e os remotos aguarda para transmitir a rajada (S1030). Se o sistema não estiver no estado estável (S1032), o mesmo volta para o estado de reamostragem (S1004) ou o mesmo vai para o estado de interrupção de consulta (S1044). Se o sistema estiver no estado estável (S1032), e o hub não tiver reiniciado ou alternado (S1034), o remoto utiliza o mecanismo de temporização de rota de entrada conforme indicado pelo hub no campo de CLT_ON no SFNP (S1036). Se esse sinalizador for falso, o mecanismo de computação de TRO é utilizado (S1040). Se esse sinalizador for VERDADEIRO, o mecanismo de CLT é utilizado (S1038). Se a CLT estiver sendo utilizada, o remoto recebe retroalimentação de temporização para cada rajada Aloha (de amostragem ou normal) e retroalimentação de temporização durante tráfego alocado sem que o erro de temporização exceda o limite de atraso de deriva de CLT conforme será discutido em maiores detalhes posteriormente. Se a computação de TRO estiver sendo utilizada, a retroalimentação de temporização é recebida somente para rajadas aloha na reamostragem; retroalimentações de temporização não são recebidas para rajadas aloha ou de fluxo normais. Nesse caso, o remoto computa sua temporização com base em suas referências salvas e no valor de THSH-EST no SFNP.

[137] Se o sistema estiver em reamostragem ou no estado de interrupção de consulta, o remoto conta com a CLT e o aloha na reamostragem. No estágio de interrupção de consulta, o remoto segue as mesmas ações conforme mostrado no estado de reamostragem (S1004 a S1014). Se o remoto estiver ocioso por menos que segundos de TOCIOSO (S1044), o mesmo pode utilizar seu último valor de TRO (S1046) para transmitir sua próxima rajada. Se o período ocioso for mais que segundos de TOCIOSO, o procedimento Aloha na reamostragem é utilizado para rajada inicial e um novo valor de TRO é recebido (S1048). Se a CLT estiver sendo utilizada, um remoto ocioso pode utilizar seu último valor de TRO (S1046) para transmitir sua próxima rajada (S1050). Um remoto recentemente instalado passa por procedimento de alcance do foco para adquirir informações de temporização para entrar na rede (S1052). O remoto aguarda para transmitir a rajada (S1054) e o estado do sistema é verificado (S1056) para ver se o mesmo está no estado de reamostragem, no estado estável ou no estado de interrupção de consulta.

[138] Se o sistema estiver no estado estável e o remoto não tiver salvado as referências (S1042), o mesmo irá salvá-las quando transmitir primeiramente no estado estável com o uso de um procedimento aloha na reamostragem.

[139] A computação de TRO por meio de estimativa de THSH é utilizada quando o sistema estiver no estável, independentemente de se o sistema está utilizado computação de CLT ou TRO para temporização. Se CLT for utilizada, a computação de TRO é utilizada somente para a rajada inicial após um intervalo ocioso. Se a CLT não for utilizada, rajadas iniciais bem como rajadas subsequentes são temporizadas com base no TRO computado. Nenhuma mensagem de correção de temporização (tal como retroalimentação de CLT) precisa ser fornecida a partir do hub para a operação desse conjunto de procedimentos.

[140] A computação de TRO por meio de conjunto de procedimentos de estimativa de THSH utiliza as seguintes ações, que são discutidos em detalhes posteriormente: 1) um processo contínuo do hub que consulta periodicamente um grupo seleto de remotos; 2) um procedimento de estimativa de THSH no hub com base nas respostas de consulta; 3) difusão do THSH estimado como parte da mensagem de SFNP a proveniente do hub; e 4) a computação de TRO no remoto com base nessa estimativa de THSH e o nos valores de referência salvos de remoto.

[141] No lançamento inicial, o sistema começa no estado de reamostragem durante o qual o mesmo utiliza aloha na reamostragem/CLT para temporização. O mesmo segue, então, certos procedimentos para transitar para o estado estável e comuta para computação de TRO para temporização. Em condições excepcionais, o sistema pode transitar do estado estável para um estado de interrupção de consulta ou voltar para o estado de reamostragem. Nesses estados, aloha na reamostragem/CLT são utilizados para temporização. Após a recuperação ser concluída, o sistema transita novamente de volta para o estado estável.

[142] O hub tem uma referência de tempo muito precisa, que é utilizada para determinar quando cada novo superquadro começa. O hub tenta transmitir o SFNP exatamente no começo de cada superquadro. No entanto, devido a atrasos de processamento no hub e devido aos pacotes de transporte de rota de saída de DVB-S2 não serem sincronizados com a temporização de quadro de hub, o hub não pode transmitir o SFNP exatamente no tempo correto. O SFNP é sempre transmitido um pouco depois do tique de tempo “ideal”. Além disso, a quantidade de tempo que o SFNP é atrasado do tempo ideal varia levemente com cada transmissão de SFNP. Adicionalmente, esse atraso é diferente para diferentes fluxos de rota de saída. A variação em tempo de transmissão de SFNP é adicionalmente explicado com a ajuda da Figura 11.

[143] A Figura 11 ilustra uma modalidade da variação em tempo de transmissão de SFNP de acordo com um aspecto da invenção.

[144] Conforme ilustrado na Figura, um eixo geométrico x 1102 denota a linha do tempo para tempos de transmissão de SFNP. Os tempos t1106, t1108 e t1110 representam os tempos de transmissão ideais para SFNP0, SFNP8 e SFNP16 respectivamente. Os tempos t1112, t1114 e t1116 representam os tempos de transmissão reais para SFNP0, SFNP8 e SFNP16 respectivamente.

[145] Apesar de o atraso e a variação de atraso serem pequenos em comparação com TSF, os mesmos são grandes em comparação com a precisão que os remotos precisam para sincronizar sua temporização com a temporização do hub. Para permitir que os remotos corrijam essa variação, que ocorre cada vez que o hub transmite um SFNP, o hub mede o atraso de tempo entre o tempo "ideal" quando o SFNP deve ter sido transmitido (o início do superquadro) e o tempo quando o mesmo foi realmente transmitido. Esse atraso também é difundido no próximo campo de Atraso de SFNP local do pacote de SFNP. Cada SFNP contém o tempo que o SFNP anterior foi atrasado de seu tempo de transmissão "ideal". Os remotos subtraem esse valor do tempo no qual os mesmos receberam o SFNP anterior para determinar quando o mesmo teria sido recebido, se o hub poderia ter enviado o mesmo exatamente no tempo correto. Esse é o ponto de referência que um remoto utiliza para seus cálculos de temporização de quadro de rota de entrada. Isso é adicionalmente explicado com a ajuda da Figura 12.

[146] A Figura 12 ilustra uma modalidade da relação de temporização entre o remoto e o hub com compensação por atraso na transmissão de SFNP, de acordo com um aspecto da invenção.

[147] Conforme ilustrado na Figura, um eixo temporal de rota de entrada 1202 é dividido em slots, quadros e superquadros, similar à Figura 6. Um quadro remoto de rota de entrada 1202 e um quadro de rota de entrada de hub 1204 representam a relação de temporização com atraso local de SFNP levado em consideração. O atraso local de SFNP é o atraso entre os tempos pretendido e real de transmissão de SFNP no hub. O atraso de SFNPN-M local é medido no hub e transmitido como parte do SFNPN para permitir que o remoto compense o atraso local na transmissão de SFNPN-M, em que M é o número de quadros/superquadro.

[148] O tempo 616 indica o tempo para a transmissão pretendida de SFNPN enquanto um tempo 1208 indica a transmissão real de SFNPN, em que o atraso é denotado por ΔTN. Observe que SFNPN contém ΔTN-8 em seu campo de atraso local. Um tempo 1210 indica a transmissão pretendida de SFNPN+8, em que SFNPN+8 contém ΔTN em seu campo de atraso local. Observe que um tempo 1214 indica a recepção pretendida de SFNPN com base na transmissão pretendida de SFNPN no tempo 616.

[149] Deixe tN-8 e tN denotar os tempos reais de recepção de SFNPN-8 e SFNPN em um tempo 1212 e um tempo 1216 no eixo temporal 1202 respectivamente para o remoto m. Quando o remoto recebe o SFNPN, o mesmo obtém o atraso local que ocorreu na transmissão de SFNPN-8 (isto é, ΔTN-8), que é contido no campo de atraso local de SFNPN. Além disso, deixe THSH-EST(tN) denotar o valor de THSH estimado no SFNPN. Com essas informações, o remoto pode calcular o tempo em que o mesmo deve transmitir a rajada, a fim de a rajada ser recebida no hub exatamente no início do quadro N de rota de entrada, conforme a seguir: ttx (N )= tN-8 — Δ TN-8 + TSF + T RO (m, tN) (3) em que o TRO estimado é computado por, T RO (m, tN) = TRO-REF (m) + 2 ( THSH_REF (M) THSH-EST (tN))) (4) e TRO-REF(m) e THSH-REF(m) são os valores de referência salvos pelo remoto m.

[150] O hub não pode controlar a temporização da transmissão de SFNP de modo que a mesma ocorra na mesma posição dentro do quadro de rota de saída em transmissões sucessivas. Consequentemente, a posição do SFNP dentro do quadro de rota de saída é variável, dependendo de quando o SFNP estiver disponível para transmissão e dos comprimentos de outros pacotes na fila. Ademais, o hub tem o conhecimento de qual quadro de rota de saída contém o SFNP, porém não pode medir o tempo exato no qual a transmissão de SFNP realmente ocorreu dentro daquele quadro de rota de saída. Para superar essa questão, o hub mede o atraso local em relação a um ponto de referência fixo dentro do quadro que contém o SFNP, ao invés de em relação a sua posição real no quadro. O remoto então utiliza o mesmo ponto de referência para medir o tempo de chegada do SFNP. Por exemplo, o hub pode medir o atraso local em relação ao início do quadro de rota de saída transmitido que contém o SFNP. Se o remoto também mede o tempo de chegada no início do quadro de rota de saída recebido que contém o SFNP, a correção de atraso local é consistente entre o hub e o remoto. Isso é adicionalmente explicado com a ajuda da Figura 13.

[151] A Figura 13 ilustra uma modalidade de medição de atraso local de SFNP de acordo com um aspecto da invenção.

[152] Conforme ilustrado na Figura, um eixo geométrico x 1302 representa o eixo temporal no hub e um eixo geométrico x 1304 representa o eixo temporal no remoto.

[153] Conforme discutido acima, ΔTN-8 indica o atraso local para a de transmissão SFNPN-8 e ΔTN indica atraso local para a transmissão de SFNPN no lado do hub. De modo similar, uma diferença de tempo 1314 indica o atraso local para recepção de SFNPN-8 e uma diferença de tempo 1316 indica o atraso local para recepção de SFNPN no lado do remoto. Uma localização 1306 indica a posição real de SFNPN-8 no quadro de rota de saída transmitido e uma localização 1310 indica a posição real de SFNPN no quadro de rota de saída transmitido. De modo similar, uma localização 1312 indica a posição real de SFNPN-8 no quadro de rota de saída recebido e uma localização 1308 indica a posição real de SFNPN no quadro de rota de saída recebido.

[154] Ao invés de medir a posição de SFNPN-8 transmitido em 1306, o hub mede o atraso local em relação a um ponto de referência fixo dentro do quadro que contém o SFNP, por exemplo, o início do quadro de rota de saída transmitido que contém o SFNP na posição 1318. De modo similar, ao invés de medir a posição de SFNPN-8 recebido em 1310, o remoto mede o tempo de chegada em relação a um ponto de referência fixo dentro do quadro que contém o SFNP, por exemplo, o início do tempo de chegada do quadro de rota de saída recebido que contém o SFNP na posição 1320.

[155] Portanto, o hub mede o atraso local em relação a um ponto de referência fixo dentro do quadro que contém o SFNP, ao invés de em relação à sua posição real no quadro. O remoto então utiliza o mesmo ponto de referência para medir o tempo de chegada do SFNP. Observe que o ponto de referência não precisa ser o início do quadro de rota de saída; o mesmo pode ser qualquer ponto que seja fixo no tempo em relação ao início do quadro de rota de saída.

[156] O processo de consulta é discutido em seguida, de acordo com aspectos da invenção.

[157] O propósito da consulta é coletar as medições de atraso de deriva conforme medido pelos remotos. O atraso de deriva conforme visto a partir da localização do remoto é medido pelo remoto como a diferença entre seu valor de TRO de referência salvo e seu valor de TRO atual. Essa é a mudança no atraso de viagem de ida e volta visto que o remoto de tempo salvou os valores de referência. Isso é aproximado visto que o TRO atual utilizado pelo remoto pode conter um erro. Visto que o valor de TRO atual é utilizado para transmitir a rajada que contém a resposta de consulta, o hub pode medir esse erro através do deslocamento de abertura da rajada recebida e aplicar uma correção, de modo que uma estimativa precisa do atraso de deriva conforme visto a partir da localização geográfica de remoto seja obtida.

[158] Além disso, o remoto também envia o valor de THSH de referência, que é ao mesmo tempo em que o TRO de referência. Aplicando-se o atraso de deriva conforme medido pela diferença nos valores de TRO de referência e atual no THSH de referência, o hub computa o THSH-EST para aquele remoto. Em qualquer instante da consulta, obtendo-se a média dos valores de THSH-EST atuais por remoto ao longo de número de remotos que são geograficamente distribuídos por todo o feixe, um THSH-EST por feixe é computado, que é difundido, então, por meio do SFNP. Qualquer remoto pode computar a média de atraso de deriva por feixe, desde o momento em que o mesmo salvou suas referências, como a diferença entre esse THSH-EST e seu THSH de referência. O remoto pode estimar, então seu TRO com base em seu TRO de referência e seu atraso de deriva computado. A precisão dessa estimativa de TRO (que transita para o comprimento de abertura) dependendo da precisão do processo de consulta, isto é, do intervalo de consulta bem como o número e distribuição de remotos que fornecem respostas de consulta. Com um intervalo de consulta da ordem de 100 segundos e 5 a 10 respostas de remotos aleatoriamente distribuídas no feixe, essa estimativa de TRO é precisa o suficiente para temporizar rajadas dentro de uma abertura da ordem de 10 microssegundos.

[159] Quando o sistema está em estado estável, o hub consulta remotos periodicamente. O intervalo entre solicitações de consulta (TCONSULTA) pode não exceder um valor máximo (por exemplo, 100 de segundos). Um intervalo de consulta menor aprimora a precisão de TRO computado em remotos e transita para um comprimento de abertura menor. Logo antes de cada instante de consulta, o hub seleciona um subconjunto de remotos que vai ser concedido alocação de largura de banda e envia solicitações de consulta a esse subconjunto de remotos. Os remotos enviam respostas de consulta na largura de banda alocada por meio de um campo de adaptação. O número de remotos selecionados para a consulta deve ser grande o suficiente para gerar o número mínimo exigido de respostas úteis de consulta, conforme será discutido em maiores detalhes posteriormente.

[160] Alguns dos remotos consultados podem não responder ou suas respostas podem não ser respondidas a tempo para a computação de THSH-EST. Alguns valores de resposta de consulta podem ser descartados como discrepâncias. Essas considerações exigem que o número de remotos consultados deve ser muito maior que o número mínimo exigido de respostas úteis (NMinPoLLResp). No entanto, a fim de garantir que respostas úteis de NminPollResp sejam geradas, o hub tem que consultar um número de remotos muito maior. Se o número de remotos disponíveis ou respostas úteis de consulta for menor, o hub não pode manter o processo de estimativa de THSH e tem que entrar no estado de interrupção de consulta. Isso é adicionalmente explicado com a ajuda da Figura 14.

[161] A Figura 14 ilustra uma modalidade do processo de consulta no hub de acordo com um aspecto da invenção.

[162] Conforme ilustrado na Figura, um eixo geométrico x 1402 representa o eixo temporal no hub para o processo de consulta. Um intervalo de consulta 1404 (TCONSULTA) indica o intervalo entre as duas solicitações de consulta pelo hub, a saber um instante de consulta 1406 e outro instante de consulta 1410.

[163] Logo antes do instante de consulta 1406 (tempo t), o hub seleciona os remotos Ra, Rb, Rc, e Rd, que vão ser concedidos alocação de largura de banda e envia solicitações de consulta a esses remotos. No tempo 1408, os remotos Ra, Rb e Rc enviam respostas de consulta na largura de banda alocada ao hub. Após aguardar pelo intervalo de consulta 1404 (TCONSULTA), o hub envia outra solicitação de consulta no tempo 1410, que é igual a (t + TCONSULTA), aos remotos Rw, Rx, Ry e Rz que vão ser concedidos alocação de largura de banda. No tempo 1412, os remotos Rx, Ry e Rz enviam respostas de consulta na largura de banda alocada ao hub.

[164] Observe que alguns dos remotos consultados podem não responder (por exemplo, o remoto Rx) ou sua resposta pode não ser recebida a tempo (por exemplo, o remoto Rd) para a computação de THSH-EST. Portanto, o número de remotos consultado deve ser muito maior que o número mínimo exigido de respostas úteis (NMinPollResp) a fim de ter número de respostas suficiente para manter o processo de estimativa de THSH no hub e evitar entrar no estado de interrupção de consulta.

[165] Quando o sistema é inicialmente lançado e está no estado de reamostragem ou está no estado de interrupção de consulta, o número de remotos ativos (isto é, os remotos com solicitações de largura de banda pendentes no hub) disponíveis para consulta é muito pequeno. Nesses casos também, o hub pode utilizar a abordagem descrita acima: isto é, consultar seletivamente remotos uma vez que um número suficiente se torna ativo no sistema. Alternativamente, o hub pode difundir solicitações de consulta para todos os remotos no feixe. Os remoto ociosos (isto é, os remotos que não têm solicitações de largura de banda pendentes, porém não estão desligados) podem responder a solicitações de consulta por meio de acesso de contenção. Essa é uma alternativa a consultar seletivamente remotos ativos e pode resultar em uma transição mais rápida de reamostragem ou interrupção de consulta para o estado estável.

[166] Se o sistema estiver no estado de reamostragem ao mesmo tempo em que se recupera de interrupção de hub, quando o hub surge, o mesmo encontrará um número grande de remotos ativos na rede. O hub pode consultar seletivamente remotos ativos e transitar para fora do estado de reamostragem muito rapidamente.

[167] Como uma regra geral, a consulta seletiva de remotos ativos é preferencial sempre que possível. Consulta de difusão é uma opção que pode ser utilizada para transitar para fora de reamostragem ou estados de interrupção de consulta, se o número de remotos ativos for menor e uma transição rápida para o estado estável for desejada. A transição para o estado estável é discutida em detalhes abaixo.

[168] O sistema transita da reamostragem (lançamento inicial ou recuperação de hub) ou dos estados de interrupção de consulta para o estado estável uma vez que o número de respostas úteis de consulta se eleva acima de um limite. Esse limite é ajustado mais alto que o mínimo exigido para fornecer histerese de modo que o sistema não altere entre os dois estados.

[169] Quando o sistema transita da reamostragem para o estado estável, os remotos que responderam à consulta recebem uma correção de TRO por meio de retroalimentação de CLT do hub. O hub pode fornecer essa retroalimentação em segundos após a transição, de modo que remotos possam salvar referências e, quando a próxima solicitação de consulta for recebida, estarem prontos para responder com referências salvas (em reamostragem após o lançamento inicial, visto que remotos não têm referências salvas, as respostas contêm valores nominais que transmitem nenhuma informação de atraso de deriva). Esses remotos salvam o valor atual de THSH-EST no SFNP e o valor de TRO corrigido como seus "valores de referência" em sua memória não volátil quando os mesmos veem essa transição. Uma vez que o sistema transitou para o estado estável, respostas de consulta que se sucederam podem ser utilizadas para computar um THSH-EST no hub, que é transmitido por meio do SFNP e os remotos utilizam essas informações para computar TRO para temporização. O processo de salvar referências para diferentes cenários será discutido em maiores detalhes posteriormente.

[170] A estimativa de THSH e o processo de computação de TRO foi simulado em uma modalidade para determinar o erro de pior cenário no TRO computado, com número de respostas de consulta e intervalo de consultas diferentes. Como esperado, o erro de TRO de pior cenário com número de respostas crescente e intervalo de consulta decrescente.

[171] O limite para transitar para o estado estável é ajustado muito mais alto que esse número visto que (i) alguns remotos ativos atualmente podem estar inativos em um instante de consulta futuro, (ii) um número de respostas pode ser eliminado como discrepâncias 3-sigma ou devido ao fato de que os mesmos não são geograficamente diversos e (iii) alteração entre os dois estados deve ser evitado. Para responder por essas responsabilidades, o hub transita para o estado estável quando o número de respostas excede o limite dado por NMinPollResp+NPollRespHist. Um limite maior é fortemente recomendado e torna o sistema mais robusto contra interrupções de consulta. É essencial, também, que essas respostas não sejam concentradas em uma parte do feixe conforme discutido posteriormente.

[172] A estimativa de THSH e o processo de computação de TRO dependem dos remotos terem salvado um conjunto de valores de temporização de referência de uma maneira controlada. O salvamento de referências ocorre infrequentemente durante operação normal - em transições de reamostragem ou interrupção de consulta para o estado estável ou como parte de alcance de foco ou aloha na reamostragem durante estado estável. Nenhum valor de referência é salvo quando o sistema está em reamostragem ou estados de interrupção de consulta. Os valores de referência são salvos na memória não volátil do remoto. Os valores de referência salvos pelos remotos são discutidos abaixo.

[173] Um dos valores de referência salvos pelo remoto é o valor de TRO corrigido mais recente (TRO-REF). O remoto obtém esse valor corrigindo-se sua estimativa de TRO atual por uma correção de TRO enviada pelo hub. O hub fornece essa correção por meio de retroalimentação de CLT a remotos consultados em transição de estado de amostragem para estado estável ou como parte de processo de alcance do foco ou em resposta a aloha na reamostragem.

[174] O outro valor de referência salvo pelo remoto é o THSH mais recente recebido por meio do SFNP (THSH-REF). O hub difunde um valor de THSH-EST valor no SFNP. O remoto salva o valor de THSH mais recente anunciado imediatamente após salvar seu valor de TRO-REF. Observe que, visto que o hub anuncia o THSH nominal no SFNP no estado de reamostragem, esse é o valor que é armazenado pelos remotos que salvam referências em transição. No estado estável, o valor de THSH-EST é atualizado após cada intervalo de consulta para rastrear deriva de satélite. Então o valor salvo é dependente do tempo em que a referência foi salvo. Além disso, o remoto também salva a situação de PollRespFlag e Versão de Referência em memória não volátil conforme descrito abaixo.

[175] PollRespFlag é inicializado para FALSO quando um remoto é instalado. No estado estável ou no estado de interrupção de consulta, um remoto responde a uma solicitação de consulta somente se esse sinalizador for VERDADEIRO (visto que o mesmo tem referências salvas válidas somente se aquele for o caso). No entanto, quando o sistema estiver no estado de reamostragem, um remoto responde à consulta independentemente da configuração desse sinalizador.

[176] A Versão de Referência identifica os processos de estimativa de THSH atual com base no qual o THSH-REF foi salvo. O propósito dessas informações é permitir que o remoto detecte se o processo de estimativa de THSH foi reiniciado quando o remoto foi desliado. Uma reinicialização pode ocorrer no caso de uma reinicialização ou alternância de hub para um hub redundante. O remoto compara esse valor com o campo de Reinicialização/Alternância de hub em SFNP e detecta se uma reinicialização/alternância ocorreu. Se tiver ocorrido, o remoto tem que salvar as referências novamente. Caso contrário, o mesmo não poderá manter a sincronização de temporização. A forma exata dessas informações não é especificada nesse pedido.

[177] Um remoto salva suas referências se e somente se uma ou mais das seguintes condições sejam verdadeiras: • O remoto é instalado e tem o foco alcançado no estado estável (valor de campo de estado de Sistema = 1 em SFNP). Nesse caso, o mesmo salva suas referências com base no valor de correção de TRO recebido como parte do procedimento de alcance de foco. • O remoto vê o valor de campo de estado de Sistema mudar de 0 para 1 (transição de estado de reamostragem para estável) em mensagens de SFNP sucessivas. O mesmo irá salvar suas referências quando o mesmo receber a próxima correção de TRO do hub. Observe que o remoto irá salvar novas referências quando isso correr, mesmo se o mesmo já tiver salvo referências. • O remoto não salvou referências e o mesmo vê valor de campo de estado de Sistema mudar de 2 para 1 (transição de interrupção de consulta para estado estável) em mensagens de SFNP sucessivas. Isso ocorre se um novo remoto foi instalado durante o estado de interrupção de consulta e uma transição ocorre da interrupção de consulta para o estado estável. O mesmo irá salvar suas referências quando receber a próxima correção de TRO do hub. • O remoto não salvou referências e vê que o sistema está em estado estável, isto é, o valor de campo de estado de Sistema em SFNP é 1 quando o mesmo deseja transmitir. Isso acontece quando um remoto for instalado no estado de reamostragem, for desligado durante a transição para o estado estável, for ligado e se tornar ativo quando o sistema estiver no estado estável. Também acontece se o remoto estiver ocioso (isto é, se estiver recebendo a rota de saída e, portanto, viu a transição, porém não estava transmitindo na rota de entrada) durante a transição e se torna ativo quando sistema estiver em estado estável. Também acontece quando um remoto for instalado no estado de interrupção de consulta. Nesse caso, o remoto utiliza um aloha na reamostragem para sua rajada inicial para obter uma correção de TRO e salvar referências. Observe que as referências podem ser salvas somente quando um remoto receber uma correção de TRO, e isso não irá ocorrer até que o remoto transmita na rota de entrada. • Um remoto que foi previamente instalado e teve o foco alcançado pode ser forçado a alcançar o foco novamente ou seguir o procedimento aloha na reamostragem, com base em um comando do o hub. Quando isso ocorre em estado estável (valor de campo de estado de Sistema = 1 em SFNP), o mesmo salva um novo conjunto de referências com base no valor de correção de TRO recebido como parte do procedimento. Tal procedimento é útil como uma ferramenta de solução de problemas para lidar com os valores de referência corrompidos no remoto.

[178] Observe que em cada um dos casos acima, o remoto obtém a correção de TRO do hub antes de salvar referências. Consequentemente, o valor de TRO-REF salvo é sempre o valor de TRO corrigido salvo imediatamente após uma correção de temporização obtida a partir do hub (devido ao alcance de foco ou aloha na reamostragem ou retroalimentação de CLT) ter sido aplicada. Em todos os casos o valor de THSH-REF salvo é o valor de THSH-EST mais recentemente anunciado no SFNP após o TRO-REF ser salvo.

[179] No estado estável, os remotos ativos selecionados que são buscando e recebendo alocação de largura de banda de rota de entrada são consultados pelo hub. Os remotos consultados respondem com certos valores de tempo diferenciais e tempo de referência (anteriormente salvos por esses remotos). O remoto pode enviar sua resposta de consulta em um intervalo de 10 segundos após a solicitação de consulta ser recebida. A resposta dos remotos pode incluir o a seguir: 1) o THSH de referência anteriormente salvo: THSH-REF; 2) a diferença entre o TRO mais recente (o TRO utilizado na temporização a rajada que contém a resposta de consulta) e o TRO de referência salvo anteriormente: ΔTRO = TRO — TRO-REF (5)

[180] 3) PollRespFlag; e 4) informações para determinar o espalhamento geográfico das respostas de consulta: Isso pode ser na forma do valor de TRO atual do remoto ou da latitude e da longitude do remoto (se disponíveis). Os valores de TRO de remoto ou informações de latitude e longitude são utilizados pelo hub para selecionar respostas dentre um subconjunto de remotos geograficamente diverso conforme será discutido em maiores detalhes posteriormente.

[181] Em inicialização e estados de interrupção de consulta também, a resposta consiste nos mesmos campos conforme indicado acima. No entanto, no estado de reamostragem, o campo de THSH-REF contém o valor de THSH que foi recebido no SFNP mais recente (THSH nominal), e os outros campos são ajustados para 0.

[182] No estado de interrupção de consulta, as respostas podem ser de remotos com referências salvas, em cujo caso todos os campos acima são ajustados consequentemente. As respostas também podem ser de remotos instalados durante o estado de interrupção de consulta, em cujo caso, o campo de THSH contém o valor que foi recebido no SFNP mais recente; outros campos são ajustados para 0.

[183] Em alguns casos, o hub recebe respostas de consulta misturadas, que são discutidas abaixo.

[184] No estado de interrupção de consulta, o hub pode receber algumas respostas de remotos que haviam ajustados anteriormente referências em estado estável (com respostas de consulta que contêm PollRespFlag = 1). O sistema está em interrupção de consulta visto que o número de tais respostas é menor que o necessário. O mesmo também pode receber respostas de remotos recentemente instalados no estado de interrupção de consulta, que não têm referências salvas (com respostas de consulta que contém PollRespFlag = 0). O último grupo está transmitindo valores nominais em sua resposta (por exemplo, ΔTRO = 0, visto que os mesmos não salvaram TRO-REF). Claramente, as respostas dos dois grupos não podem ser utilizadas juntamente para computar THSH-EST. Há duas opções para o hub nesse caso conforme discutido abaixo.

[185] Em uma modalidade (opção 1), o hub pode ignorar as respostas dos remotos recentemente instalados e aguardar até que o número de respostas de remotos com referências salvas exceda o limite antes de transitar para o estado estável. Nesse caso, o processo de THSH-EST é contínuo com aquele antes da interrupção de consulta e é consistente com as referências já salvas por remotos na rede. Essa abordagem é preferencial quando o número de remotos na rede com referências salvas for maior que o número dos remotos recentemente instalados no estado de interrupção de consulta. Em contrapartida, se o número de remoto com referências salvas for menor (possível no caso de redes pequenas), essa abordagem pode prolongar a duração do estado de interrupção de consulta. Em uma modalidade, quando o número de remotos for esperado ser em dezenas de centenas/feixe ou mais, essa é a abordagem recomendada para lidar com respostas misturadas no estado de interrupção de consulta. O método apresentado nessa aplicação é baseado nessa abordagem.

[186] Em outra modalidade (opção 2), o hub pode transitar para o estado estável quando o número total de respostas de ambos os grupos exceder o limite. Um remoto ativo nessa transição irá salvar um novo conjunto de referências, independentemente de se o mesmo for um remoto recentemente instalado ou um remoto com referências anteriormente salvas. (Os remotos que estão inativos nessa transição, porém tinham referências anteriormente salvas, precisam detectar que os mesmos têm que salvar novas referências quando os mesmos se tornarem ativos novamente no estado estável). As respostas de consulta subsequentes seriam baseadas nas novas referências, que iniciam um novo processo de THSH-EST que não é consistente com as referências salvas pelos remotos antes da interrupção de consulta. O hub utiliza a "identificação de reinicialização/alternância de GW" no SFNP para anunciar que um novo THSH-EST começou. Com base nisso, os remotos com referências antigas salvam suas referências novamente logo que os mesmos se tornam ativos no estado estável (como se uma reinicialização de hub tenha ocorrido). Se o número de remotos com referências salvas for menor que os remotos recentemente instalados no estado de interrupção de consulta, (possível no caso de redes pequenas), essa abordagem é preferencial visto que a mesma acelera a transição para o estado estável. Por outro lado, em uma rede com um número grande de remotos que tinham referências anteriormente salvas, essa não é uma opção atraente pela seguinte razão: quando tais remotos se tornam ativos novamente no estado estável e constatam que os mesmos têm que salvar novas referências, os mesmos terão que utilizar aloha na reamostragem para obter correções de TRO. Aloha na reamostragem utiliza slots de contenção não alocados e uma abertura grande e seu uso deve ser minimizado.

[187] No estado de reamostragem após também o reinício/comutação do hub, as respostas misturadas podem ser recebidas pelo hub. Mas o hub pode misturar as respostas nesse caso (conforme no caso 2 acima), dado que o mesmo iniciará um novo processo de estimativa de THSH de qualquer forma. Nesse caso, todos os remotos irão salvar um novo conjunto de referências (similar ao caso 2 acima e com uma retirada grande para a aloha na reamostragem). No estado de reamostragem após o lançamento inicial, esse problema não é encontrado dado que nenhum dos remotos tem referências salvas.

[188] A seguir, discute-se correções para erros de temporização da rajada de resposta a consulta no hub de acordo com um aspecto da invenção.

[189] Note que o TRO usado na computação do ΔTRO na resposta de consulta é o TRO computado pelo remoto para transmitir a rajada que contém a resposta de consulta. Esse TRO pode conter um erro. O hub irá determinar o erro de temporização para essa rajada e aplicar uma correção ao ΔTRO para compensar pelo erro de temporização. Em outras palavras, o hub irá corrigir esse ΔTRO de forma que o mesmo se torne, efetivamente, a diferença entre o TRo ideal (isto é, o TRo que atinge o centro da abertura) e a referência TRo-REF do remoto.

[190] Discute-se, a seguir, a distribuição geográfica de remotos de acordo com um aspecto da invenção.

[191] o hub tem de selecionar um subconjunto de respostas a partir dos remotos distribuídos no decorrer do feixe. Se as coordenadas de latitude e longitude do remoto tiverem sido inseridas durante a instalação, os remotos enviam essa informação como parte da resposta de consulta. Caso essa informação não esteja disponível, cada remoto envia seu TRO atual como parte da resposta de consulta. O hub aplica uma correção a esse TRO com base no deslocamento de abertura da rajada para determinar o TRO ideal (TRO-CORR) que teria resultado na rajada que atinge o centro da abertura. Isso é descrito mais adiante. Os remotos localizados próximos uns dos outros terão valores TRO-CORR que são próximos uns dos outros. Diferenças maiores nos valores TRO-CORR de remotos indicam que os remotos estão mais distantes uns dos outros (o inverso não é necessariamente verdadeiro). O hub pode examinar a distribuição de valores TRO-CORR a partir das respostas de consulta e selecionar um subconjunto que é distribuído no decorrer de uma faixa.

[192] Um algoritmo simples para essa seleção, de acordo com um aspecto da invenção, pode ser esboçado conforme a seguir: 1) deixar TRO-MIN-TRO-MAX representar a faixa de todos os valores TRO-CORR possíveis para um dado feixe. Essa faixa é conhecida a priori para um dado THO, feixe e hub; 2) dividir essa faixa em segmentos NTRO. Espera-se que um valor de NTRO = 5 seja satisfatório em uma modalidade; 3) para cada segmento, determinar a número de respostas de consulta das quais os valores TRO-CORR estejam dentro daquele segmento; 4) encontrar o menor número Nmín no decorrer de todos os segmentos; 5) a partir de cada segmento, selecionar aleatoriamente Nmín respostas das quais os valores TRO-CORR estiverem nesse segmento; e 6) isso fornece um total de respostas de consulta Nmín * NTRO que são consideradas geograficamente diversas o suficiente para a computação do THSH-EST. Esse número deve satisfazer Nmín * NTRO > NMínPollResp, o que pode ser assegurado consultando-se um grande número de remotos.

[193] Se as coordenadas de latitude e longitude de remoto estiverem disponíveis, o algoritmo acima pode ser usado com algumas modificações mínimas em uma modalidade exemplificativa: 1) o feixe é geograficamente dividido em setores NTRO; 2) as respostas de remoto são localizadas dentro dos setores com base em sua latitude e sua longitude em sua resposta de consulta; 3) para cada setor, determinar o número de remotos dos quais os valores TRO-CORR estão dentro daquele setor; 4) a partir de cada setor, selecionar aleatoriamente Nmín respostas das quais os valores TRO-CORR estavam naquele setor; e 5) isso fornece um total de respostas de consulta Nmín * NTRO que são consideradas geograficamente diversas o suficiente para a computação do THSH-EST. Esse número deve satisfazer Nmín * NTRO > NMínPollResp, o que pode ser assegurado consultando-se um grande número de remotos.

[194] Discute-se, a seguir, a estimativa para THSH no hub de acordo com um aspecto da invenção.

[195] Os valores de referência a partir do subconjunto de respostas de consulta são usados no hub para computar um valor THSH estimado que é difundido como parte do SFNP. Em uma modalidade, cada hub mantém uma estimativa de THSH separada para cada um de seus quatro feixes (estimativa de THSH por feixe). Essa abordagem fornece reduções significativas na abertura em comparação com uma estimativa para THSH.

[196] Note que esse procedimento é aplicável somente quando o sistema está em estado estável, isto é, quando o sistema tiver passado por um estado de reamostragem e houver remotos na rede que tenham ajustado suas referências e respondido à consulta.

[197] O hub ignora respostas a partir de remotos com PollRespFlag ajustado como FALSO. Isso pode acontecer quando o sistema estiver em estado de reamostragem (quando nenhum remoto tiver referências salvas) ou em estado de interrupção de consulta (se um remoto for instalado durante o estado de interrupção de consulta). Somente respostas com PollRespFlag = VERDADEIRO são usadas em estimativa para THSH.

[198] Esse procedimento é usado para computar o THSH-EST somente se o hub receber um número suficiente de respostas úteis (> NMínPollResp, consulte ação 5 abaixo). Discute-se mais tarde o caso em que esse número é insuficiente.

[199] O algoritmo de estimativa para THSH em uma modalidade exemplificativa pode ser descrito pelas cinco ações a seguir.

[200] Primeiro, há ações preliminares. O hub mantém e atualiza um THSH-EST (de acordo com as ações 2 a 5 abaixo) para cada feixe e difunde esse THSH-EST estimado no SFNP para os remotos nesse feixe. Cada remoto ativo recebe essa informação. Além disso, os remotos têm valores THSH e TRO "de referência" salvos. O késimo remoto salva suas referências em tREF(k) como: i) o valor THSH que foi difundido em SFNP mais próximo ao tREF(k) como THSH_REF(K), e 11) o valor TRO em tREF(k) como TRO-REF(k).

[201] Para uma segunda ação, em um tempo t, o hub consulta remotos dentro de cada feixe. Para propósitos de discussão, deixar N dentre os remotos no grupo consultado, por acaso, é ativo e fornece uma retroalimentação ao hub. A retroalimentação a partir do remoto k**1 no grupo consultado inclui: a) THSH-REF(k) e b) ΔTRo(k,t) = TRo(k,t) - TRo-REF(k), em que TRO(k,t) é o TRO computado pelo késimo remoto para a transmissão da rajada que contém a resposta de consulta.

[202] Para uma terceira ação, para propósitos de discussão, presume-se que a rajada usada para enviar essa resposta de consulta chega ao hub a um deslocamento de T0fj k,t) em relação ao centro da abertura. o hub pode computar um ΔTRO corrigido (isto é, o ΔTRO no qual teria resultado, caso o remoto tivesse usado o ΔTRO ideal que atinge o centro da abertura) como ΔTRo-CoRR (k,t) = ΔTRo(k,t) + Toff(k,t) (6)

[203] Para uma quarta ação, o ΔTRo da equação (6) é um resultado da deriva do satélite conforme visto pelo késimo remoto consultado entre os tempos t e tREF(k). o hub aplica isto como uma correção ao valor THSH-REF(K) relatado pelo késimo remoto para a computação de THSH-CoRR(k,t) = THSH-REF(k)— 0,5 * ΔTRo-CoRR(k,t) (7)

[204] Para uma quarta ação, a estimativa de THSH por remoto é ponderada pelo decorrer de um subconjunto dos remotos que responderam à consulta para obter a estimative de THSH-EST(t) atual para aquele feixe:

Aqui, N' é o número de remotos no subconjunto que foram selecionados de forma que (1) haja alguma diversidade geográfica, conforme descrito anteriormente e (2) dos quais o THSH-CORR(k,t) esteja dentro dos limites 3-sigma. As amostras de discrepâncias que estejam fora dos limites 3- sigma são excluídas para uma melhor precisão de estimativa. Além disso, o número de amostras remanescentes após as discrepâncias serem excluídas (TV) pode exceder um certo número mínimo (NMínPollResp) para assegurar que a estimativa é aceitável. Se esse número for muito pequeno, a estimativa de THSH não é atualizada (isto é, o THSH-EST(t) permanece a mesma). Esse caso excepcional será discuto em maiores detalhes mais tarde.

[205] A estimativa de THSH resultante é difundida no SFNP dentro do feixe até que o próximo evento de consulta ocorra e as ações 2 a 5 sejam repetidas.

[206] Discute-se, a seguir, a computação de TRO no remoto com base em THSH-EST em SFNP de acordo com um aspecto da invenção.

[207] Se o sistema estiver em estado estável e a CLT estiver desabilitada, um remoto que deseja transmitir uma rajada, determina sua temporização computando-se um TRO com o uso de THSH-EST do SFNP mais recente e de seus valores de referência salvos. Se o sistema estiver em estado estável e a CLT estiver habilitada, a computação de TRO é usada, mas somente para a rajada de aloha inicial após TIDLE segundos tiverem passado desde a última correção CLT. Note que a fim de usar a técnica de computação de TRO, um remoto pode ter salvo seus valores de referência. A computação de TRO é resumida pela seguinte ação.

[208] Presume-se que um remoto m arbitrário precisa determinar a temporização para sua próxima rajada no tempo t e que o mesmo salvou suas referências. Isso pode ser um remoto ativo com tráfego em corrente (alocado) ou um remoto saindo de um longo estado de repouso que precisa computar a temporização para sua rajada de aloha inicial. O THSH-EST(t) contido no SFNP mais recente é obtido e usado para estimar o TRO através de:

[209] Esse valor TRO é usado pelo remoto para determinar o tempo de início de quadro (SoF) para quadro de T número N contido no SFNP. Esse estimado difere do TRO exato para o remoto (isto é, o valor que resultaria na rajada do remoto que atinge o centro da abertura) por um componente de erro. Esse erro se deve ao fato que o atraso de deriva aplicado ao TRO-REF na equação acima é um atraso de deriva ponderado por feixe, que é diferente do atraso de deriva conforme visto por aquele remoto particular. O valor máximo desse erro determina o tamanho da abertura necessária para receber a rajada no hub.

[210] O sistema entra o estado de interrupção de consulta devido a um número inadequado de respostas de consulta úteis. Discute-se, a seguir, o caso de número de respostas de consulta inadequadas, de acordo com um aspecto da invenção.

[211] O processo de estimativa de THSH e, portanto, a abordagem de computação de TRO depende de maneira crítica em receber a resposta de consulta a partir dos remotos que salvou suas referências. Alguns remotos salvam as referências na transição do estado de reamostragem. Outros salvam as referências em estado estável através de alcance de foco ou aloha na reamostragem. Qualquer remoto que tiver salvo as referências pode ser consultado e, sua resposta, usada na computação de THSH-EST (isto é, isto não é restrito a remotos que tiverem salvo as referências na transição). Sob condições normais em estado estável, o número de respostas de consulta facilmente excede o NMínPollResp mínimo necessário), dado que o mínimo necessário é bastante modesto quando comparado ao número de remotos em um feixe. Entretanto, sob condições incomuns, tais como uma interrupção de energia regional ampla, é possível que o número de respostas de consulta fique abaixo desse mínimo e o THSH-EST não possa ser computado. Se um novo THSH-EST não for computado no fim de um intervalo de consulta, o atraso de deriva durante o intervalo não pode ser rastreado. O erro possível no TRO estimado aumenta e a rajada pode não ser recebida dentro da abertura normal.

[212] Quando o número de respostas de consulta úteis (N') for pequeno demais (0<N‘<NMínPoiiResp), o hub passa por transição ao estado de interrupção de consulta. Nesse estado, os remotos usam uma aloha na reamostragem para atingir a sincronização e a CLT iniciais durante as transmissões de corrente. O hub continua a consultar remotos e monitorar respostas em estado de interrupção de consulta. Entretanto, o valor de THSH-EST não é atualizado e o mesmo permanece congelado no último valor computado em estado estável. O sistema irá passar por transição ao estado estável uma vez que o número de respostas de consulta N' seja superior a NMínPollResp + NPollRespHist.

[213] O sistema entra no estado de interrupção de consulta devido a um número inadequado de respostas de consulta úteis. Esse estado é indicado a remotos para ajustar o campo de estado de Sistema = 2 em SFNP. Embora similar ao estado de reamostragem em grande parte, também há algumas diferenças. As similaridades são as seguintes. Primeiro o hub fornece uma retroalimentação de temporização para cada rajada de Aloha e uma retroalimentação de CLT durante o tráfego alocado sempre que o erro de temporização exceder o limite de atraso de deriva de CLT conforme descrito mais tarde. O CLT é habilitado definindo-se o sinalizador de CLT ATIVADA em SFNP para VERDADEIRO e configurando-se o Limite de Deriva de CLT = Td, que é < 0,5*comprimento de abertura para CLT em uma modalidade. Segundo, os remotos usam uma aloha na reamostragem se mais do que TIDLE segundos tiverem passado desde a última correção de TRO a partir do hub. Terceiro, o sistema irá passar por transição de saída desse estado quando recebe um número adequado (> NMÍnPollResp+NPollRespHist) de respostas para solicitações de consulta.

[214] As diferenças são: 1) o hub continua a transmitir no SFNP o THSH-EST mais recente computado em estado estável (isso será chamado de "THSH-EST congelado" adiante); e 2) a transição ao estado estável ocorre somente após: a) um número adequado de respostas de consulta úteis serem recebidas, N' > NMínPollResp+NPollRespHist (10) e b) um novo THSH-EST for computado com base nessas respostas e difundido no SFNP.

[215] Por exemplo, o campo de estado de sistema em SFNP deveria comutar de 2 para 1 somente quando o novo THSH-EST tiver sido computado e anunciado no SFNP. Isso é muito importante dado que os remotos que forem instalados durante o estado de interrupção de consulta e estiverem ativos durante a transição ao estado estável salvarão o THSH no SFNP no tempo de transição como uma referência. Sendo assim, essa referência pode ser o valor computado a partir das respostas consultadas e não do valor THSH-EST congelado transmitido durante o estado de interrupção de consulta. Isso é necessário para manter a continuidade no THSH-EST anunciado no SFNP antes e depois de o sistema ter entrado em interrupção de consulta. Dado que a resposta de consulta foi computada com base em remotos que tinham salvo referências antes de a interrupção de consulta, o novo THSH -EST será consistente com o THSH-EST de antes da interrupção e incorporará a deriva de satélite que ocorreu durante o intervalo de interrupção.

[216] Conforme discutido anteriormente, a abordagem acima para sair da interrupção de consulta é com base na continuação do processo THSH-EST que estava presente no estado estável antes da interrupção de consulta ter ocorrido, em vez de restabelecer um novo conjunto de referências (por exemplo, opção 1 em vez de a opção 2 conforme discutido anteriormente). Se a opção 2 for implantada, a transição ao estado estável é mais rápida, mas todos os remotos com referências salvas terão de salvar as referências novamente, em sua maioria através da aloha na reamostragem. Nesse caso, entretanto, o estado de interrupção de consulta se torna idêntico ao estado de reamostragem no caso de reinício ou comutação de hub.

[217] O CLT de acordo com um aspecto da invenção é discutido em detalhes abaixo.

[218] Quando o sistema está em estado de reamostragem, os remotos ativos dependem da retroalimentação de CLT para receber as correções aos seus TRO a partir do hub. Uma abertura normal pode ser usada no hub para receber essas rajadas.

[219] Quando o sistema está em estado estável, ou o mecanismo de computação de TRO descrito anteriormente ou o mecanismo de CLT descrito abaixo podem ser usados. O hub pode ativar a CLT definindo-se o limite de CLT de deriva Td<0,5*comprimento de abertura e anunciar aos remotos que usam a CLT definindo-se o sinalizador CLT ATIVADA em SFNP para VERDADEIRO. Note que somente um (dentre a computação de TRO ou CLT) pode estar em uso tempo a ser usado. Quando o sistema comuta entre os dois métodos, o remoto detecta essa mudança com base no sinalizador CLT ATIVADA em SFNP. Após comutar da computação de CLT para TRO, o remoto pode ignorar quaisquer pacotes de retroalimentação de CLT que possam ser recebidos.

[220] Para tráfego aloha, se a CLT estiver ativa, o hub fornece uma retroalimentação de correção de temporização como parte de sua resposta a cada rajada de aloha a partir de um remoto. Tais rajadas podem ser para dados de usuário, mensagens de atividade de suporte principal PEP e respostas às solicitações de consulta SNMP ou solicitações BW. Isso possibilita que o remoto corrija seu TRO imediatamente e mantenha sua precisão para rajadas de abertura normal. Se a CLT não estiver ativa, o hub fornece uma retroalimentação de correção de temporização somente para rajadas de ou alcance de foco ou aloha na reamostragem a partir de um remoto. O hub não fornece uma retroalimentação de correção de temporização para rajadas de aloha normal.

[221] Para tráfego de corrente, se CLT estiver ativa, os remotos que estão transmitindo ativamente o tráfego de corrente recebem mensagens de CLT consolidadas a partir do hub para corrigir suas estimativas de TRO. Nesse caso, uma mensagem de correção de temporização pode não ser enviada a cada remoto individual imediatamente, mas sim agregada no decorrer de múltiplos quadros e remotos para impedir o uso excessivo da largura de banda de rota de saída. O mesmo pode ser resumido conforme segue. Primeiro, o remoto transmite uma rajada de corrente em sua largura de banda alocada, com base em sua estimativa de TRO atual. Então, o hub monitora o erro de temporização para rajadas a partir de cada remoto (isto é, a diferença entre o centro da abertura e o último símbolo da palavra única (UW)). Então, se pelo menos THO segundos tiverem passado desde a última mensagem de correção de temporização a esse remoto e o erro de temporização exceder um limite de atraso de deriva configurável (como uma porcentagem do comprimento de abertura), o hub adiciona o remoto à sua lista de remotos que precisam receber uma retroalimentação de correção de temporização. Então uma mensagem de correção de CLT consolidada é enviada aos remotos nessa lista se pelo menos uma dentre as duas condições a seguir forem satisfeitas: a) o número de remotos na lista exceder um certo número mínimo; e/ou b) uma mensagem de correção de temporização estiver pendente para o remoto na lista por mais do que um certo número de quadros. Então o remoto recebe a mensagem de correção de CLT, e faz essa correção a seu TRO. Finalmente, quando um remoto deseja transmitir uma rajada e tiver recebido uma correção de temporização dentro dos últimos < TIDLE segundos, o mesmo irá usar o TRO corrigido mais recente para temporizar sua rajada. Entretanto, se > TIDLE segundos tiverem passado desde a última correção de temporização, o TRO corrigido mais recente não é utilizável. O remoto perdeu a sincronização. Se o sistema estiver em estado estável, o remoto precisa usar a computação de TRO para sua rajada inicial. Se o sistema estiver nos estados de reamostragem ou de interrupção de consulta, o mesmo precisa da aloha na reamostragem para sua rajada inicial, conforme será discuto em maiores detalhes mais tarde. Após o hub enviar uma correção em resposta à rajada inicial, pode ser dada continuidade ao CLT.

[222] Conforme é evidente a partir do que é posto acima, a CLT é um mecanismo para manter a sincronização de temporização uma vez que um remoto tenha alcançado a sincronização. O mesmo não fornece um mecanismo para alcançar uma sincronização inicial, por exemplo, para caso o remoto tenha ficado ocioso ou desligado por um longo período de tempo (sem correções TRO a partir do hub para > TIDLE segundos) e tiver perdido a sincronização de temporização. Nesse caso, a deriva de satélite durante o período ocioso tornará o TRO mais recente do CLT impreciso demais para temporizar a rajada com uma abertura normal.

[223] No estado estável, o remoto usa a computação de TRO com base no THSH-EST no SFNP e suas referências armazenadas para computar a temporização inicial. No estado de reamostragem, o mesmo usa a aloha na reamostragem. Discute-se, a seguir, a aloha na reamostragem para casos especiais de acordo com um aspecto da invenção.

[224] A aloha na reamostragem é um mecanismo usado no estado de reamostragem, no estado de interrupção de consulta ou, sob casos especiais, em estado estável. Um exemplo de um caso especial é quando o sistema está em estado de reamostragem ou de interrupção de consulta, o hub está fornecendo a retroalimentação de CLT, mas o remoto não recebeu uma retroalimentação de correção de temporização CLT para > TIDLE e, portanto, não pode usar seu TRO anterior para sua rajada inicial. Em outro exemplo, o sistema está em estado estável, mas o remoto não salvou as referências. Portanto, o mesmo não pode computar a temporização através da computação de TRO. Isso pode acontecer se o remoto tiver tido o intervalo ajustado em estado de reamostragem, mas tiver sido desligado durante a transição ao estado estável.

[225] A aloha na reamostragem é uma rajada de aloha enviada em um canal não alocado de alcance de foco. OS conteúdos da rajada são similares àqueles de uma rajada de alcance de foco não alocada. O hub irá incluir uma retroalimentação de correção de temporização na mensagem de confirmação de aloha. O remoto transmite a rajada de aloha na reamostragem com o uso de uma estimativa de TRO bruta com base no THSH-EST no SFNP (que pode ser CoB com base em satélite) e no código zip do remoto (assim como para as rajadas de alcance de foco). Portanto, essa rajada necessita do uso de uma abertura longa. A retroalimentação de temporização recebida em resposta possibilita que o remoto corrija seu TRO para rajadas de abertura normal.

[226] O uso de aloha na reamostragem é limitado a casos nos quais não existirem outras alternativas. Dado que a rede é configurada com muito poucos slots não alocados de alcance de foco, a mesma pode ser sobrecarregada se numerosos remotos estiverem se tornam ativos após seus períodos ociosos ao mesmo tempo e recorrerem à aloha na reamostragem.

[227] Discute-se abaixo uma modalidade exemplificativa na qual o remoto se recupera de um ócio longo e o sistema está em estado de interrupção de consulta e reamostragem.

[228] Quando o sistema está em estado de reamostragem, os remotos não salvaram suas referências. Além disso, o SFNP contém um THSH bruto com base em coordenadas CoB de satélite. Quando o sistema está em estado de interrupção de consulta, os remotos instalados recentemente em estado de interrupção de consulta não salvaram suas referências. Nesse estado, o SFNP contém o THSH-EST mais recente computado antes de entrar no estado de interrupção de consulta. Um remoto ativo receberá correções de CLT ao TRO e pode manter uma temporização de quadro. Se tiver recebido a correção de temporização dentro dos últimos < TIDLE segundos, o mesmo ainda pode usar o TRO mais recente quando sair do estado de repouso. A abertura normal é dimensionada para tolerar o atraso de deriva no decorrer de um intervalo de no máximo TIDLE. O hub pode usar a abertura normal para receber tais rajadas. Se a correção de temporização for mais antiga (recebida > TIDLE segundos atrás), o mesmo não pode usar o TRO anterior. Nesse caso, o remoto pode usar a aloha na reamostragem para reentrar na rede.

[229] Uma modalidade exemplificativa, quando o remoto se recupera de um ócio longo e o sistema está em estado estável é discutida abaixo.

[230] Um remoto pode ser instalado e receber alcance de foco em estado de reamostragem ou de interrupção de consulta, mas pode estar ocioso ou desligado quando a transição ao estado estável ocorre. Tal remoto não salvou suas referências e, portanto, não pode computar um TRO preciso quando se torna ativo. Se um remoto entrar no estado ativo durante o estado estável e constatar que não tem referências salvas (PollRespFlag = FALSO para o remoto), o mesmo irá usar a aloha na reamostragem para enviar sua primeira rajada. Esse remoto define as referências após receber a correção na confirmação de aloha na reamostragem. Subsequentemente, o mesmo pode usar a estimativa de THSH de estado estável no SFNP e suas referências salvas para determinar valores TRO de acordo com o procedimento descrito mais tarde.

[231] Uma modalidade exemplificativa de alcance de foco para remotos instalados recentemente é discutido abaixo.

[232] Um remoto novo pode ser instalado e receber a alcance de foco em estado estável. Tal remoto salva seus valores alcance de foco como valores de referência. Os valores de referência salvos são o THSH-REF e o TRO-REF conforme descrito anteriormente. Adicionalmente, o PollRespFlag é ajustado como VERDADEIRO de forma que o mesmo possa responder às solicitações de consulta. Subsequentemente, o mesmo pode usar a estimativa de THSH no SFNP para determinar o valor TRO para temporizar suas rajadas (se a CLT estiver desabilitada) ou usar a retroalimentação de CLT (se a CLT estiver habilitada).

[233] Um remoto instalado recentemente segue os procedimentos de alcance de foco para determinar seu TRO. O procedimento de alcance de foco consiste nas ações a seguir de acordo com um aspecto da invenção, entretanto, o procedimento abaixo é modificado de forma que as alocações de alcance de foco não sejam usadas para temporização; o hub fornece a correção de temporização de alcance de foco em resposta à transmissão em slots não alocados de alcance de foco: • Frequência de rota de saída e aquisição de temporização • Sincronização de frequência de rota de entrada • Sincronização de Superquadro: Isso possibilita que o remoto receba o SFNP. Isso, por sua vez, possibilita que o remoto adquira a sincronização de número de quadro de rota de entrada e o valor da estimativa de THSH sendo anunciado pelo hub. • O remoto computa um atraso entre satélite e remoto aproximado (TSR-ZC), aproximando-se a localização do remoto pelas coordenadas de seu código zip e pela localização do satélite como o centro da caixa de manutenção da estação (THSH-NOM). A partir disso, um TRO bruto é computado com: • TRO = THO - THSH-NOM — 2TSR-ZC (11) • O remoto usa o TRO bruto para transmitir uma "rajada de aloha de alcance de foco" em um canal não alocado de alcance de foco. • O hub emprega uma "longa abertura" para receber essa rajada, dado que isso se baseia em um TRO bruto. Essa abertura também é conhecida como "abertura para alcance de foco" e é na ordem de milissegundos. Isso contrasta com a "abertura normal" que tem dezenas de μseg de extensão que o hub usa para rajadas de dados designados e rajadas de aloha a partir de remotos que já tiveram suas referências salvas e de intervalo ajustado. • O hub mede o intervalo de tempo entre o início da abertura e o tempo de chegada da rajada de aloha de alcance de foco a partir do remoto. Essa correção é enviada ao remoto como parte da resposta de aloha. • O remoto usa isso para corrigir o TRO bruto. Esse TRO corrigido possibilita que o remoto temporize suas rajadas de forma que possam ser recebidas com o uso de uma abertura normal muito mais estreita no hub.

[234] Duas modalidades exemplificativas para o manuseio da interrupção de hub são discutidas a seguir. Em uma modalidade, um hub ou um componente no hub que controla a temporização pode se desligar e reiniciar. Isso implica na existência de uma perda de informação relacionada aos estados do hub ou ao estado do processo de estimativa de THSH. Em outra modalidade, um hub pode ser desabilidade e um hub redundante pode passar a controlar os feixes que eram servidos pelo hub que foi desabilitado.

[235] Lida-se com ambos os casos acima da mesma forma: o hub primário reiniciado ou o hub redundante inicia em estado de reamostragem (campo de estado de sistema = 0 em SFNP). Quando os remotos constatam que o sistema está em estado de reamostragem, os mesmos dependem de uma combinação de aloha na reamostragem e CLT para temporização. Dado que é provável que um grande número de remotos esteja presente na rede e disputem o número limitado de canais de aloha não alocados, anuncia-se uma grande retirada de aloha no SFNP de forma que os remotos que acessam a rota de entrada através da aloha na reamostragem não sobrecarreguem a capacidade disponível de aloha. Uma vez que um número suficiente de remotos tenha entrado na rede e que os processos de consulta, de estimativa para THSH tenham iniciado, o sistema passa por transição do estado de reamostragem ao estado estável com o uso dos procedimentos descritos anteriormente. Note que dado que um processo de estimativa de THSH é iniciado, os remotos que salvaram anteriormente as referências precisam salvar novas referências. Uma comparação do valor da versão de Referência salva contra o campo de identificação do reinício/comutação do hub em SFNP indicam a um remoto se uma comutação/reinício de hub ocorreu enquanto o mesmo estava desligado. Mediante a detecção desse evento, o remoto salva um novo conjunto de referências com o uso de aloha na reamostragem.

[236] Os amplos conceitos subjacentes dos mecanismos de temporização de rota de entrada de acordo com os aspectos da invenção são resumidos pelas ações conforme discutido abaixo.

[237] Quando o sistema é inicialmente lançado, o mesmo inicia em um estado de reamostragem e passa por transição a estado estável, quando um procedimento de estimativa para THSH pode ser iniciado. Em estado de reamostragem, um procedimento de retroalimentação de CLT e de aloha na reamostragem é usado para a temporização de rota de entrada. Em estado estável, a computação de TRO nos remotos é usada para a temporização de rota de entrada.

[238] Começando no lançamento do sistema, o hub transmite um SFNP em cada corrente de difusão única DVB-S2 de cada carreador de rota de saída para cada um de seus feixes. O SFNP fornece um número de quadro de rota de entrada para sincronização de número de quadro, um valor THSH para temporização de rota de entrada, um campo de estado de sistema para indicar se o sistema está em um estado de reamostragem, uma interrupção de consulta ou estado estável, um sinalizador de CLT ATIVADA para indicar se o sistema está usando um mecanismo de computação de TRO ou CLT.

[239] Começando no lançamento do sistema, o hub transmite as solicitações de consulta em intervalos que não excedem um certo intervalo (por exemplo, centenas de segundos). As solicitações de consulta podem ser enviadas por difusão seletiva para um grupo específico de remotos ou difundidas a todos os remotos no feixe.

[240] Inicialmente, em estado de reamostragem, o número de respostas de consulta será pequeno. O mesmo aumenta conforme novos remotos são instalados. Quando o número de respostas excede um mínimo, o sistema passa por transição a estado estável.

[241] Os remotos instalados recentemente usam um alcance de foco para obter a sincronização de temporização de rota de entrada inicial.

[242] Os remotos salvam certos valores de temporização de referência para ajudar o hub na computação de um valor THSH. Os remotos instalados em um estado de reamostragem e que estão ativos na transição da reamostragem ao estado estável salvam as referências durante a transição. Os remotos instalados em um estado estável salvam essas referências com base em valores recebidos no alcance de foco. Os remotos que foram instalados na reamostragem, mas não salvaram as referências durante a transição, salvam essas referências com base nos valores recebidos após um procedimento de aloha na reamostragem, quando se tornam ativos pela primeira vez em um estado estável

[243] Os remotos respondem a solicitações de consulta a partir do hub transmitindo-se a referência salva e valores de atraso diferenciais. Esses valores relatam o atraso de deriva de satélite (entre o tempo em que as referências foram salvas e o tempo de resposta de consulta) conforme visto por cada um dentre os remotos consultados.

[244] O hub computa um THSH-EST nos valores de atraso de deriva recebidos a partir de consulta. Esse THSH-EST é difundido como o valor THSH no SFNP. Esse valor contém a média de atraso de deriva visto pelo grupo de remotos que responderam à consulta. A fim de que esse atraso de deriva médio seja representativo (consultado ou não consultado) dos remotos no feixe, é importante ter um certo número de respostas mínimo para cada solicitação de consulta e um certo grau de diversidade geográfica nas respostas de consulta.

[245] Durante o estado estável, a temporização pode ser com base em computação de TRO ou CLT, uma escolha que é controlada pelo hub. O CLT pode ser desativado configurando-se um limite de atraso de deriva de forma que as mensagens de correção de temporização não sejam disparadas no hub. Nesse caso, o sinalizador de CLT ATIVADA é ajustado como FALSO no SFNP para anunciar aos remotos que usem a computação de TRO. A CLT pode ser reativada reconfigurando-se adequadamente o limite de atraso de deriva Td e definindo-se o sinalizador de CLT ATIVADA = VERDADEIRO em SFNP. A decisão de usar CLT ou TRO é influenciada principalmente pela complexidade da implantação.

[246] Em estado estável, se uma computação TRO for usada (isto é, se a CLT estiver desativada), um remoto que precisar transmitir uma rajada computa seu TRO com base no THSH-EST do SFNP e seus valores de referência salvos. Note que a computação de TRO no remoto não necessita de quaisquer mensagens de retroalimentação de temporização a partir do hub.

[247] Em estado estável, se a CLT estiver sendo usada, o hub fornece correções de TRO a remotos quando o deslocamento de abertura exceder um limite de atraso de deriva Td. Se tiverem passado mais do que TIDLE segundos predeterminados desde a correção anterior, o remoto usa a computação de TRO para transmitir sua primeira rajada e dá continuidade as correções com base em CLT.

[248] Se o número de respostas de consulta for inferior ao mínimo necessário, o sistema entra no estado de interrupção de consulta, durante o qual o mesmo retorna para CLT e para aloha na reamostragem para a temporização de rota de entrada. O mesmo reentra no estado estável quando o número de respostas exceder novamente um limite que exceda o mínimo por um número que forneça histerese.

[249] Para alcance de foco ou aloha na reamostragem, o hub usa uma abertura relativamente longa. Um exemplo não limitante de uma abertura relativamente longa é em milissegundos.

[250] Para CLT, o hub usa uma abertura normal de dezenas de μseg. A CLT é usada durante os estados de reamostragem e de interrupção de consulta e pode também ser usada durante o estado estável.

[251] Para a temporização com base na computação de TRO, o hub usa uma abertura normal de dezenas de μseg. A computação de TRO pode ser usada somente durante o estado estável.

[252] Se um hub que estiver atualmente servindo um conjunto de feixes for desabilitado, os remotos nos quatro feixes associados ao mesmo podem ser comutados com um dos hubs redundantes, que inicia em um estado de reamostragem. Se um hub ou um componente crítico de hub se desligar e for reiniciado, pode não haver comutação de feixes, sendo que o hub reinicia em estado de reamostragem.

[253] Discute-se abaixo a transição do sistema, do lançamento inicial, através do estado de reamostragem até o estado estável, e o comportamento do hub e de remotos durante essa transição, com a ajuda da Figura 15.

[254] A Figura 15 ilustra as interações entre o hub e os remotos conforme o sistema passa pela transição de estado de reamostrage para o estado estável, de acordo com um aspecto da invenção.

[255] Conforme ilustrado na Figura, um processo 1500 inclui as interações entre o hub e o remoto para a sincronização de temporização. Note que os valores de temporização ilustrados em referência à Figura são somente a título exemplificativo e podem não representar os números reais de temporização.

[256] No lançamento do sistema, em uma ação 1502 e uma ação 1504, o hub transmite SFNPs aos remotos com um THSH-NOM nominal. O SFNP fornece um número de quadro de rota de entrada para a sincronização de número de quadro, um valor THSH para a temporização de rota de entrada, um campo de estado de sistema e um sinalizador de CLT ATIVADA. No lado do remoto, o remoto R1 está ativo após um longo intervalo ocioso e segue os procedimentos de instalação e de alcance de foco.

[257] Em uma ação 1506 o hub transmite solicitações de consulta aos remotos em intervalos. O remoto R1 transmite uma resposta de consulta em uma ação 1508 e efetiva um procedimento de aloha na reamostragem em uma ação 1510.

[258] O hub continua a enviar o SFNP com THSH-NOM e as solicitações de consulta. O mesmo também fornece a retroalimentação de CLT ao remoto Ri em uma ação 1512. O hub inicialmente ignora o número insuficiente de respostas de consulta.

[259] No lado do remoto, muitos outros remotos (R2-RM), são instalados, passam por alcance de foco e são ativados. Em uma ação 1514, o remoto R1 transmite uma rajada de corrente para o que o hub fornece uma retroalimentação de CLT em uma ação 1516. O hub fornece a retroalimentação de CLT aos remotos (R1-RM).

[260] O hub continua a enviar as solicitações de consulta em uma ação 1520 e recebe as respostas de consulta dos remotos (R1-RM) transmitidas em uma ação 1522. O mesmo continua, adicionalmente, a enviar o SFNP com THSH-NOM em uma ação 1524 e fornece a retroalimentação de CLT aos remotos (R1-RM) em uma ação 1526. Agora, um número de remotos suficiente está respondendo à consulta para o sistema se mover ao estado estável.

[261] Os remotos (R1-RM) salvam as referências THSH-REF = THSH-CURRENT e TRO-REF é igual à correção de TRO anterior dentro de um curto intervalo.

[262] O campo de estado de sistema em SFNP é mudado para T, de '0', para indicar a transição ao estado estável. O hub continua a enviar solicitações de consulta em uma ação 1528.

[263] Os remotos (R1-RM) respondem à solicitação de consulta com valores de referência salvos em uma ação 1530.

[264] O hub computa o THSH-EST com base na resposta de consulta e difunde-o aos remotos em SFNPs futuros em uma ação 1532. O hub continua a enviar as solicitações de consulta aos remotos ativos em uma ação 1534.

[265] Os remotos respondem a solicitações de consulta em uma ação 1536. Os remotos instalados recentemente passam por alcance de foco com o THSH-EST e o código zip de TRO para alcance de foco. Os remotos salvam as referências como THSH- REF= THSH-EST e TRO-REF = TRO RANGING.

[266] O hub computa o THSH-EST com base na resposta de consulta e atualiza o THSH-EST em SFNP em uma ação 1538.

[267] Os remotos instalados recentemente seguem procedimento de aloha no alcance de foco em uma ação 1540 ao qual o hub envia uma resposta de alcance de foco em uma ação 1542.

[268] Os remotos que passaram por alcance de foco em estado de reamostragem e estavam ociosos durante a transição ao estado estável (isto é, não definiram referências), se tornam ativos e seguem o procedimento de aloha na reamostragem em uma ação 1544. Esses remotos salvam as referências como THSH-REF = THSH-EST e o TRO-REF é igual à correção de TRO anterior. O hub envia uma resposta de aloha na reamostragem, em uma ação 1546, a esses remotos.

[269] O hub desativa o mecanismo de CLT agora e continua a enviar as solicitações de consulta aos remotos ativos em uma ação 1548. Os remotos consultados continuam a responder a solicitações de consulta em uma ação 1550, sempre que não estiverem desligados.

[270] O hub continua a receber respostas de consulta e a computar o THSH-EST com base nessas respostas de consulta. Além disso, o mesmo continua a enviar o SFNP, com o THSH-EST computado, aos remotos, nas ações 1552, 1554 e 1556.

[271] O hub continua a enviar as solicitações de consulta aos remotos ativos em uma ação 1558. Os remotos consultados continuam a responder às solicitações de consulta em uma ação 1560. Os remotos que salvaram referências usam o THSH-EST no SFNP recebido e suas referências para estimar um TRO para temporizar sua transmissão. Isso se aplica a estados ativos, após estados curtos ou longos de repouso ou a estados desligados de remotos.

[272] O hub continua a enviar o SFNP com o THSH-EST computado a remotos em uma ação 1562.

[273] Conforme discutido anteriormente, em estado estável, um remoto com referências salvas pode computar um TRO-EST (com base no THSH-EST e nas referências) e também um TRO-CLT (um TRO corrigido com base na retroalimentação de CLT). Um mecanismo de acordo com um aspecto da invenção é apresentado a seguir para assegurar que as condições de corrida sejam evitadas e que o remoto selecione passe pela transição, apropriadamente, entre valores TRO-EST e TRO-CLT. Em estado estável, o hub está conduzindo uma consulta, processando a resposta de consulta para estimar o THSH-EST e anunciando-a no SFNP, conforme descrito previamente. O hub também fornece uma retroalimentação de correção de CLT a um remoto se o erro de deslocamento de abertura de uma rajada exceder o limite de atraso de deriva, conforme descrito anteriormente.

[274] Uma condição de corrida entre o TRO-CLT e o TRO-EST pode ocorrer mediante um cenário conforme discutido a seguir. Presume-se que um remoto transmite uma rajada em quadro N, no tempo tN, que foi temporizado com o uso de TRO(tN). Presume-se que essa rajada é recebida no hub com o deslocamento de abertura ΔTRO > limite de atraso de deriva Td. Isso aciona uma mensagem de CLT ao remoto, com uma correção valor de ΔTRO. A mensagem de CLT é recebida pelo remoto no tempo IM > IN. De fato, presumindo-se a pior situação de atraso de propagação de remoto a hub de N milissegundos, e que o hub espera por até TMáxCLTDelay antes de a mensagem de CLT ser transmitida, tM — tN - TMáxCLTDelay + 2*N seg.

[275] Um valor típico para TMáxCLTDelay é 1 segundo em um exemplo. O remoto pode identificar que a correção recebida é aplicável a TRO(tN), o que pode não necessariamente ser o TRO atual no remoto. Se um ciclo de consulta não tiver completado no intervalo tN-tM, o valor de THSH-EST não mudou, então o TRO atual = TRO(tN), Nesse caso, a correção é aplicável ao TRO atual. Entretanto, se um ciclo de consulta tiver completado no intervalo tN-tM, os valores de THSH-EST e TRO podem ter mudado. Nesse caso, o TRO atual^ TROUN) e a correção recebida não é aplicável ao TRO atual.

[276] A fim de evitar a condição de corrida, propõe-se as seguintes medidas. Em uma modalidade, a mensagem de correção de CLT indica o número de quadro de rota de entrada para o qual a correção é aplicável. o remoto mantém um segundo registro de pares anteriores {de número de quadro de rota de entrada e valor TRo usado}. Esse registro deve ser mantido pela duração de pelo menos TMáxCLTDelay + 2*N seg. Isso parte do princípio que o hub não aguarda mais do que TMáxCLTDelay segundos antes de transmitir uma mensagem de CLT após uma rajada exceder o limite de atraso de deriva e de que o atraso máximo de propagação de ida e volta do remoto ao hub é de 2* N segundos.

[277] Quando o remoto recebe uma mensagem de CLT com um quadro número N, o mesmo constata que a correção de TRo é aplicável a partir de sua lista de {números de quadro de rota de entrada e valores TRo usados}. A correção de CLT é aplicada ao TRo(tN) para obter

Se, por algum motivo, o remoto constatar que não tem o registro para o quadro N, o mesmo ignora a mensagem de CLT.

[278] Um método de acordo com um aspecto da invenção é apresentado para combinar o TRo-EST e o TRo-CLT para determinar um valor TRo. Isso somente é possível em estado estável, dado que o TRo-EST é computado com o uso de e referências de remoto e de THSH-EST, que somente estão disponíveis em estado estável. Em estado estável, a cada intervalo de consulta de TPOLL segundos, o hub computa um novo valor THSH-EST, o qual é anunciado no SFNP. Um remoto com referências salvas pode computar um TRO-EST após o mesmo receber cada SFNP. Isso pode ser usado para a temporização do próximo superquadro.

[279] Se o remoto tiver transmitido previamente e uma de suas rajadas tiver excedido o limite de atraso de deriva, o mesmo irá receber também uma correção de TRO a partir da qual o mesmo irá computar um TRO-CLT, conforme descrito anteriormente. A partir desses dois candidatos diferentes ao TRO, o remoto precisa gerar um valor de TRO único, que é usado para determinar a temporização de quadro para o próximo superquadro. Um algoritmo exemplificativo para fazer isso é esboçado abaixo em termos de ações executadas em cada superquadro.

[280] Primeiro, se nenhuma mensagem de CLT tiver sido recebida desde o último SFNP, usa-se TRO = TRO-EST para temporizar o próximo superquadro e aguardar o próximo SFNP. Do contrário, o remoto continua em diante à segunda ação.

[281] Em segundo lugar, com base na mensagem de CLT recebida desde o último SFNP, o TRO-CLT é computado.

[282] Em terceiro lugar, um temporizador configurável TTIMER-CLT é iniciado.

[283] Em quarto lugar, o TRO = TRO-CLT é usado para a temporização do próximo superquadro. O temporizador TTIMER-CLT é adicionalmente decrementado. Se o temporizador não tiver expirado, o remoto permanece nessa ação. Se o TTIMER-CLT tiver expirado, o remoto continua à próxima ação.

[284] Em quinto lugar, uma transição de volta ao TRO-EST é iniciada. Em uma modalidade exemplificativa: o remoto primeiro aguarda pelo próximo SFNP. Se uma mensagem de CLT tiver sido recebida nos TSF segundos anteriores (superquadro), o TRO-CLT é computado com base em uma mensagem de CLT. Então, o remoto computa um TRO-EST a partir do THSH-EST e de referências salvas. Se |TRO-CLT-TRO-EST| < 1 μseg, a transição ao TRO-EST é completada - e o remoto continua à próxima ação. Do contrário, o remoto modifica TRO-CLT em 1 microssegundo conforme segue: a) se TRO-CLT < TRO-EST, aumenta- se em 1 μseg: TRO-CLT = TRO-CLT + 1; e b) se TRO-CLT > TRO-EST, diminui-se em 1 μseg: TRO-CLT= TRO-CLT- 1. Então o remoto usa TRO = TRO-CLT para a temporização para essa superquadro. Nesse momento, se |TRO-CLT-TRO-EST| < 1 μseg, a transição ao TRO-EST é completada - e o remoto continua à próxima ação.

[285] Em sexto lugar, o remoto ajusta TRO = TRO-EST e retorna à primeira ação.

[286] Na segunda ação, o motivo para usar o TRO-CLT resultante é que garante-se haver um erro de abertura <= unidades de μseg. Em contraste, é provável que o TRO-EST tenha um erro de abertura superior ao limite de atraso de deriva Td (isto é, >= dezenas de μseg) dado que uma mensagem de CLT foi acionada.

[287] Na primeira ação, note que usa-se TRO = TRO-CLT pelo menos até que um temporizador expire. Um valor adequado para o temporizador é TPOLL segundos. Isso garante que o TRO-CLT seja usado até que um ciclo completo de consulta seja completado, um novo valor THSH-EST seja computado e anunciado no SFNP. Isso aborda o caso no qual pode haver um problema com a resposta de consulta e o valor THSH-EST resultante.

[288] O propósito da quinta ação é passar pela transição de TRO-CLT a TRO-EST gradualmente em vez de instantaneamente. Isso é importante dado que, se ainda houver um problema sério com o TRO-EST, comutando-o sem "validá-lo", a sincronização de temporização pode ser perdida. Na ação 5d, verifica-se se TRO-EST se "aproximou" de TRO-CLT, caso no qual o TRO-EST é um valor válido e para o qual pode-se comutar com segurança. Se não tiver se aproximado (Etapa 5e), o TRO-CLT é ajustado em ações de 1 μseg para se direcionar gradualmente a TRO-EST. Caso haja um problema sério com o TRO-EST que resultaria em um grande deslocamento de erro de abertura, conforme o TRO-CLT se direciona a TRO-EST em ações de 1 microssegundo, para algumas rajadas, o erro de deslocamento atravessará o limite de atraso de deriva e acionará outra mensagem de CLT. Isso força o uso de TRO-CLT por pelo menos outros TTIMER-CLT segundos. Esse processo irá se repetir até que o TRO-EST tenha recuperado sua precisão.

[289] O valor TRO resultante do processo acima, para um remoto m, após receber o SFNPN, é definido como

. Isso é usado na determinação da temporização de quadro de rota de entrada do superquadro N, conforme será discutido em maiores detalhes posteriormente.

[290] Conforme discutido referência às Figuras 4 a 15, os aspectos da invenção fornecem duas técnicas para a sincronização de temporização, com base em CLT e consulta, que podem ser combinadas de diferentes formas para uma forma ideal. Na abordagem com base em CLT, o hub transmite mensagens de retroalimentação de correção de temporização específicas de remoto na rota de saída conforme necessário, o que possibilita que o satélite transmita o mais próximo possível do meio da abertura da rajada. Na abordagem com base em consulta, os remotos derivam sua temporização com base em uma difusão de estimativa de atraso médio por feixe pelo hub e em um atraso local medido específico para cada corrente de rota de saída a partir do remoto. O hub calcula um atraso médio por feixe com base nas respostas de consulta a partir de uns poucos remotos selecionados com base nas solicitações de consulta e difunde-o a todos os remotos no feixe. Os remotos usam essa estimativa de atraso para corrigir a temporização de sua transmissão em vez de usar a retroalimentação de CLT.

[291] Outra modalidade exemplificativa da invenção será agora descrita, na qual usa-se triangulação para estimar as coordenadas de satélite. Esse método deve ser aplicado junto com CLT.

[292] O hub consultará pelo menos 3 remotos (preferencialmente 4) para enviar de volta seu atual TRO. Isso é feito com base em superquadro e a réplica precisa chegar também dentro de um superquadro. A periodicidade da consulta pode ser reduzida para N = 4 superquadros, mas a réplica dos remotos precisa chegar dentro de M = 2 superquadros. O hub calcula a distância THSH do satélite conforme mostrado abaixo e transmite essa informação dentro do SFNP. Com esse valor sendo difundido no SFNP, o remoto pode enviar a aloha de abertura comum mesmo após ligar ou após estar ocioso por algumas horas (isto é, sem receber a retroalimentação de CLT).

[293] É preciso que as posições de latitude e de longitude dos remotos sejam conhecidas com precisão o que, em um exemplo, pode ser obtido com o uso de GPS. O cálculo de THSH é efetivado conforme discutido abaixo e pode ser explicado com a ajuda de uma Figura 16.

[294] A Figura 16 ilustra uma modalidade exemplificativa da invenção para calcular as coordenadas de satélite com o uso de triangulação.

[295] Uma caixa de manutenção da estação 1602 inclui a posição anteriormente conhecida do satélite 1604, marcada como (a,b,c) e a posição atual do satélite 1606, marcada como (x,y,z). Um remoto 1608, um remoto 1610 e um remoto 1612 se comunicam com um hub 1614 através da caixa de manutenção da estação 1602.

[296] Cada um dentre o remoto 1608, o remoto 1610 e o remoto 1612 também relata sua latitude e longitude e altura e seu TRO atual quando solicitado pelo hub 1614.

[297] Os seguintes cálculos são feitos no hub 1614. Primeiro, a latitude/longitude geodésica são convertidas em XEC, YEC, ZEC em no sistema de coordenadas centradas na Terra: Os valores intermediários R1 e R2 são calculados:

em que: a é o raio equatorial da Terra, ∫ um fator planificante, h é a altura, em metros, do ponto de interesse, acima da elipsoide de referência, e 0 = Latitudedeg * A (latitude geodésica em radianos) Com relação a h, as variações máximas na altura entre a elipsoide de referência e o nível ponderado do mar são de aproximadamente 100 metros e podem ser ignoradas. Os parâmetros a ser usados nos cálculos incluem: Raio equatorial da Terra (a) = 6.378.137 metros (modelo WGS 84); Fator planificante (f) = 1 / 298,25722 (modelo WGS 84 ); Raio da órbita (RORB) = 42.164.000 metros; e Velocidade da luz (c) = 299792458 m/segundos. XEC, YEC, ZEC então são calculados:

em que:

Portanto (x, y, z) para cada remoto e o hub são obtidos.

[298] O procedimento para a determinação da posição do satélite é discutido abaixo.

[299] Deixar (a, b, c) ser a posição previamente conhecida do satélite no tempo t0. Em uma modalidade exemplificativa, inicialmente, a mesma poderia ser o centro da caixa de manutenção da estação. Deixar (x, y, z) ser a posição atual (desconhecida) do satélite no tempo ti. Deixar fi (x, y, z) ser a distância entre a posição atual do satélite e o remoto i. Deixar fi (a, b, c) ser a distância entre a posição anterior conhecida do satélite e o remoto i. Então, a distância e o tempo entre o hub e a posição anterior conhecida do satélite é calculada:

[300] A partir do TRO medido de cada um dos remotos, a distância entre o remoto e o satélite atual é calculada

[301] A distância entre cada remoto e a posição anterior conhecida do satélite é dada por

[302] A distância entre cada remoto e a posição atual do satélite é dada por

[303] Resolvendo-se a equação (25) para (x, y, z) com o uso de uma expansão da Série de Taylor

[304] Então, a distância do hub ao satélite e de volta é calculada e, então, convertida para temporizar o THSH, que é enviado no SFNP

[305] Uma modalidade exemplificativa de hub 1614 que usa o método de triangulação conforme descrito acima, de acordo com um aspecto da presente invenção, será descrita agora com referência à Figura 17.

[306] Conforme ilustrado na Figura 17, o hub 1614 inclui uma porção de comunicações 1702, uma porção geodésica 1704, uma porção de computação 1706, uma porção de cálculo de distância de hub 1708 e uma porção de cálculo de distância de remoto 1710. Nesse exemplo, a porção de comunicações 1702, a porção geodésica 1704, a porção de computação 1706, a porção de cálculo de distância de hub 1708 e a porção de cálculo de distância de remoto 1710 são elementos distintos. Entretanto, em algumas modalidades, pelo menos duas dentre a porção de comunicações 1702, a porção geodésica 1704, a porção de computação 1706, a porção de cálculo de distância de hub 1708 ou a porção de cálculo de distância de remoto 1710 podem ser combinadas como um elemento unitário. Em outras modalidades, pelo menos uma dentre a porção de comunicações 1702, a porção geodésica 1704, a porção de computação 1706, a porção de cálculo de distância de hub 1708 ou a porção de cálculo de distância de remoto 1710 podem ser implantadas como um computador que tenha armazenada em si um meio tangível legível por computador para portar ou ter instruções legíveis por computador ou estruturas de dados armazenadas na mesma.

[307] A porção de comunicações 1702 se comunica com a porção geodésica 1704 através de um sinal 1712, e com a porção de cálculo de distância de hub 1708 e a porção de cálculo de distância de remoto 1710 através de um sinal 1716. Adicionalmente, a porção de comunicações 1702 se comunica de maneira bidirecional com a porção de computação 1706 através de um sinal 1726.

[308] A porção de comunicações 1702 é operável para receber uma pluralidade de rajadas do satélite, as quais podem ser transmitidas a partir do remoto 1608, do remoto 1610 e do remoto 1612 com referência à Figura 16. Cada rajada recebida pela porção de comunicações 1702 inclui um atraso de propagação estimado correspondente para cada remoto e também as informações de latitude, longitude e altura.

[309] A porção geodésica 1704 se comunica com a porção de computação 1706 através de um sinal 1714, se comunica com porção de cálculo de distância de hub 1708 através de um sinal 1718 e se comunica com porção de cálculo de distância de remoto 1710 através de um sinal 1722.

[310] A porção geodésica 1704 é operável para receber as informações de latitude, longitude e altura para cada remoto a partir da porção de comunicações 1702 e para fornecer XEC, YEC, ZEC à porção de cálculo de distância de hub 1708 e à porção de cálculo de distância de remoto 1710 para calcular a distância do hub e dos remotos da posição conhecida do satélite.

[311] A porção de cálculo de distância de hub 1708 é operável para fornecer a distância entre o hub e o satélite com base nas coordenadas fornecidas pela porção geodésica 1704, conforme indicado pela equação (19), à porção de computação 1706, através de um sinal 1720.

[312] A porção de cálculo de distância de remoto 1710 é operável para fornecer a distância entre cada remoto e o satélite com base nas coordenadas fornecidas pela porção geodésica 1704, conforme indicado pela equação (24), à porção de computação 1706, através de um sinal 1724.

[313] A porção de computação 1706 é operável para computar a posição atual do satélite com base na distância entre o hub e o satélite fornecida pela porção de cálculo de distância de hub 1708, a distância entre cada remoto e o satélite fornecida pela porção de cálculo de distância de remoto 1710 e o atraso de propagação estimado correspondente para cada remoto.

[314] Uma vez que a posição atual do satélite esteja determinada, a distância do hub ao satélite e de volta é calculada e, então, convertida para temporizar o THSH, que é enviado no SFNP conforme indicado pela equação (38).

[315] Outro método alternativo de rastrear o movimento do satélite é o uso de dados de efemérides do satélite. Os dados de efemérides consistem nas coordenadas x, y e z do satélite a cada cinco minutos. Os mesmos são previstos com antecedência de três dias e os arquivos que contêm esses dados são fornecidos aos hubs a partir do Centro de controle de Satélite. Dado que tanto a posição do hub quanto a do satélite são conhecidas, o THSH de atraso de tempo pode ser calculado e então transmitido no SFNP.

[316] Um refinamento adicional é possível se as coordenadas do remoto forem conhecidas com precisão (por exemplo, inseridas durante a instalação com o uso de coordenadas de GPS). Nesse caso, o hub pode anunciar as coordenadas atuais do satélite a todos os remotos no feixe, com base nos dados de efemérides no SFNP. Dado que o remoto tem ciência das coordenadas de remoto, de satélite e de hub, cada remoto pode computar sua temporização de rota de entrada (isto é, TRO) com precisão.

[317] Propõe-se um algoritmo alternativo em uma modalidade exemplificativa que usa a rajada de temporização de hub em vez de depender da consulta. O mesmo depende do fato do hub medir os deslocamentos de rajada de rajadas de tráfego e a estimativa de um TRO médio de feixe, o qual é anunciado em SFNP. Esse algoritmo tem vantagens sobre a abordagem atual, bem como implicações na implantação e no processamento necessário no hub.

[318] Um algoritmo exemplificativo de acordo com um aspecto da invenção é esboçado abaixo.

[319] Primeiro, o hub difunde um SFNP, o qual tem um campo chamado TRO-AVG. Inicialmente, quando não existem remotos no estado de reamostragem inicial, esse campo contém um valor nominal. O valor nominal pode ser o valor TRO computado com o uso das coordenadas de centro de feixe e de CoB de satélite. O hub continua a anunciar o valor nominal até que um remoto passe por alcance de foco e comece a transmitir rajadas. Uma vez que o hub tenha recebido algumas rajadas, o mesmo começa a atualizar o TRO- AVG e pode passar por transição ao estado estável.

[320] Para propósitos de discussão, deixa-se um remoto m ser adicionado estado de reamostragem inicial no tempo t0. O remoto m passa por alcance de foco e obtém seu TRO ideal (=TRO-RNG(m)) com base na retroalimentação de alcance de foco. O remoto m computa um "deslocamento único" ΔTRo(m) = TRO—RNG(m) - TRO-AVG( to) (39) O remoto m, então, salva o deslocamento único computado em sua memória não volátil. Todos os remotos salvam seus "deslocamentos únicos" durante seu alcance de foco.

[321] Quando o hub recebe uma rajada a partir de qualquer remoto m em um tempo t, algumas coisas acontecem. o hub computa o deslocamento da rajada a partir do centro da abertura, diga-se, e(m,t). Isso representa o erro entre o TRo ideal e a estimativa de TRo usada pelo remoto. o mesmo pode inclui também qualquer outro erro aleatório no sistema, que são ignorados pelo tempo: e(m,t) = TRo-IDEAL(m,t) - TRo(m,t) (40) Note que somente o erro é necessário, não os valores de TRo atual ou ideal. No decorrer de um período de tempo [ 11 — 12), o hub computa a média de deslocamentos de todas as rajadas recebidas durante esse intervalo: eAVG(t1,t2) = Média de e(*,t) para todas as rajadas recebidas para t em [t1 - t2). No tempo t2, o hub atualiza seu TRO-AVG anunciado conforme segue: TRO-AVG(t2) = TRO-AVG(t1)+ eAVG(t1,t2) (41) Esse processo continua no estado estável. O intervalo de ponderação [t1 - t2) não deve exceder uns poucos segundos. Além disso, para limitar a carga de processamento, um subconjunto de rajadas selecionado aleatoriamente, em vez de todas as rajadas, pode ser usado na ponderação.

[322] Um remoto que deseja transmitir uma rajada no tempo t, computa seu TRO com o uso do TRO-AVG(t) anunciado presentemente e de seu ΔTRO de deslocamento único salvo, conforme segue: TRO(m,t) = TRO-AVG(t) + ΔTRO(m) (42)

[323] A ideia basicamente é que se, em média, as rajadas estão entrando atrasadas, reduz-se o TRO-AVG anunciado no SFNP, de forma que os TROS computados futuramente nos remotos sejam reduzidos. Se as rajadas estiverem, em média, chegando cedo, então aumenta-se o TRO- AVG.

[324] Uma modalidade exemplificativa de um hub para uso em um método de chegada de rajada em hub, de acordo com um aspecto da presente invenção, será agora descrita com referência à Figura 18.

[325] Conforme ilustrado na Figura, um hub 1800 inclui uma porção de comunicações 1802 e uma porção de computação de deriva de temporização 1804. Nesse exemplo, a porção de comunicações 1802 e a porção de computação de deriva de temporização 1804 são elementos distintos. Entretanto, em algumas modalidades, a porção de comunicações 1802 e porção de computação de deriva de temporização 1804 podem ser combinadas como um elemento unitário. Em outras modalidades, pelo menos uma dentre a porção de comunicações 1802 e a porção de computação de deriva de temporização 1804 pode ser implantada como um computador que tenha armazenada em si um meio tangível legível por computador para portar ou ter instruções legíveis por computador ou estruturas de dados armazenadas na mesma.

[326] A porção de comunicações 1802 se comunica de maneira bidirecional com a porção de computação de deriva de temporização 1804 através de um sinal 1806.

[327] A porção de comunicações 1802 é operável para receber uma pluralidade de rajadas a partir do satélite e é operável adicionalmente para transmitir o deslocamento médio calculado pela porção de computação de deriva de temporização 1804, aos remotos, através do satélite.

[328] A porção de computação de deriva de temporização 1804 é operável para computar uma pluralidade de deslocamentos correspondente à pluralidade de rajadas, respectivamente, a partir de um centro de abertura, e para calcular um deslocamento médio com base na pluralidade de deslocamentos. O deslocamento da rajada a partir do centro de abertura para um remoto m computado pelo hub é representado pela equação (40). A média de deslocamentos de todas as rajadas recebidas no decorrer de um período de tempo é usada pelo hub para calcular seu TRO-AVG anunciado que é transmitido aos remotos pela porção de comunicações 1802.

[329] A Figura 19 ilustra a relação de temporização dos dois remotos em um feixe em relação ao TRO em uma modalidade exemplificativa.

[330] Conforme ilustrado na Figura, uma plotagem 1900 inclui um eixo geométrico x 1904 para tempo (minutos) e um eixo geométrico y 1906 para TRO (milissegundos). Uma curva 1908 representa o TRO para o remoto 1 (terminal 1) e uma curva 1910 representa o TRO para o remoto 2 (terminal 2). Outra curva 1902 inclui um eixo geométrico x 1912 para o tempo (minutos) e um eixo geométrico y 1914 para a diferença em TRO (milissegundos). Uma curva 1916 representa a diferença no remoto 1 e no remoto 2. O remoto 1 e o remoto 2 podem ser espacialmente separados no feixe.

[331] O TRO-AVG pode ser visto como uma média de TRO por feixe (e adicionado a uma constante). Se as rajadas vindas forem distribuídas uniformemente no feixe, essa média é o TRO de um remoto no centro do feixe. Em geral, essa média está em constante movimento na direcionado ao "centro de massa de tráfego da rota de entrada" instantâneo. Obviamente, se o tráfego for enviesado em direção a uma parte do feixe, a média também é enviesada. O algoritmo depende do fato que mesmo na presença de erros (espaciais, temporais e aleatórios), o TRO-AVG corresponderá a algum ponto dentro do feixe e não derivará para fora do feixe.

[332] Isso pode introduzir um erro, conforme ilustrado pela curva 1916, dado que a mudança necessária para um remoto particular pode ser diferente da média. Mas esse erro pode estar limitado a um valor menor, dado que os feixes direcionados são limitados em tamanho. Por exemplo, considere que as rajadas são a partir do canto do feixe e, portanto, o deslocamento médio de rajada direciona o TRO-AVG ao canto do feixe. Para um remoto no canto oposto do feixe, haveria um erro devido à separação espacial entre os dois cantos. Em um instante no tempo, dado o valor de TRO para qualquer remoto dentro do feixe, o valor TRO de qualquer outro remoto no feixe pode ser expressado como igual ao deslocamento constante somado ao erro, em que o erro tem uma magnitude de <= ±2,35 μseg. Portanto, o erro devido à separação espacial é de <= 2*2,35 μseg = 4,7 μseg (conforme mostrado pelos pontos 1918 e 1920). Também haverá um erro temporal devido ao intervalo de atualização, mas o mesmo é negligenciável conquanto que o intervalo de atualização se limite a alguns segundos. A abertura precisaria levar em consideração esses erros e também os erros devido à precisão das medidas de temporização no hub e no remoto.

[333] É concebível se preocupar com problema a respeito da possibilidade de acúmulo desses erros com o tempo, o que pode fazer com que o TRO-AVG divirja. Essa possibilidade tem sido analisada até certo ponto, mas não parece ser o caso.

[334] O método também presume que nenhum feixe transponha a longitude do satélite. Se esse não for o caso, os remotos em ambos os lados podem passar por deriva de maneira uniforme, o deslocamento de rajada médio seria zero, mas os remotos poderiam passar por deriva para fora da abertura.

[335] O método discutido acima tem similaridades (por exemplo, reamostragem, interrupção de consulta, salvamento de referências, estimativa de média anunciada, etc) com a estimativa para a abordagem de THSH conforme discutido anteriormente, mas também há diferenças. As diferenças entre as duas abordagens são evidenciadas abaixo.

[336] Primeiro, não á um processo de consulta, então não há solicitações de consulta ou respostas de consulta. O hub usa o deslocamento de abertura de rajadas de tráfego para computar seu valor anunciado de TRO-AVG.

[337] Em segundo lugar, dado que o intervalo entre as rajadas de tráfego é muito menor do que o intervalo de consulta típico (poucos segundos contra centenas de segundos), é possível atualizar o TRO-AVG mais constantemente. Isso significa que o atraso de deriva não rastreado entre a consulta não precisa ser considerado no comprimento de abertura. Os comprimentos de abertura podem, portanto, ser menores (em alguns segundos). Obviamente, o mesmo é possível no método de estimativa para THSH se o intervalo de consulta for reduzido em alguns segundos.

[338] Em terceiro lugar, se não houver tráfego na rota de entrada, existe uma situação análoga à interrupção de consulta, isto é, o TRO-AVG não pode ser atualizado e o atraso de deriva não é rastreado. Após algum tempo (alguns segundos), o TRO-AVG não pode ser usado para temporizar as rajadas. O hub pode entrar em um estado de "interrupção de consulta" e anunciar seu estado no SFNP. Um remoto que seja ligado após esse estado ser alcançado pode usar a aloha na reamostragem para temporizar sua primeira rajada. Quando o hub recebe a rajada de aloha na reamostragem, o mesmo pode dar continuidade à atualização do TRO-AVG.

[339] Em quarto lugar, há implicações para o processamento/implantação do hub. O hub precisa processar cada rajada vinda (ou um subconjunto de rajadas aleatoriamente selecionado), isto é, o deslocamento de rajada, dado que cada rajada precisa ser computada e ponderada pelo decorrer de um intervalo de alguns segundos. Esse processo precisa ser mantido de maneira contínua.

[340] Uma técnica de sincronização de temporização de acordo com os aspectos da presente invenção pode ser usada em um sistema que não tenha acesso às informações de efemérides do satélite na passagem ou no terminal.

[341] Além disso, uma técnica de sincronização de temporização de acordo com os aspectos da presente invenção pode ser usada em um sistema no qual a passagem não tem a capacidade de receber sua própria transmissão, devido ao fato de que a passagem pode ser localizada fora da área de cobertura do feixe a partir do satélite. Em contraste com alguns sistemas convencionais, uma passagem precisa se localizar dentro da área de cobertura do feixe devido ao fato de que a mesma deve ter a capacidade de receber sua própria transmissão para determinar a posição do satélite.

[342] Além disso, uma técnica de sincronização de temporização de acordo com os aspectos da presente invenção pode ser usada independentemente das localizações da passagem e do feixe, bem como do formato do feixe (feixe direcionado ou feixe CONUS). Adicionalmente, a passagem e os feixes de usuário podem se localizar em hemisférios ou continentes diferentes.

[343] Além disso, uma técnica de sincronização de temporização de acordo com os aspectos da presente invenção não depende de uma detecção precisa da localização do terminal através de GPS. Entretanto, as informações de GPS podem ser usadas para acentuar aspectos particulares.

[344] A descrição antecedente de várias modalidades preferenciais da invenção foi apresentada para propósitos de ilustração e descrição. A mesma não se destina a ser exaustiva ou a limitar a invenção às formas precisas reveladas e, obviamente, muitas modificações e variações são possíveis tendo em vista as instruções acima. As modalidades exemplificativas, conforme descrito acima, foram escolhidas e descrita a fim de explicar os princípios da invenção e sua aplicação prática da melhor forma possível para, portanto, tornar possível que outras pessoas versadas na técnica utilizem a invenção, da melhor forma possível, em várias modalidades e com várias modificações, conforme adequado ao uso particular contemplado. Destina-se que o escopo da invenção seja definido pelas reivindicações anexadas a este.

Claims

1. Método para sincronização de quadros em um sistema de comunicação por satélite, compreendendo: consultar um subconjunto dentre uma pluralidade de terminais remotos (112, 114, 116, 118) de uma rede de comunicações de satélite, e receber uma resposta de pesquisa de cada um dos terminais remotos pesquisados; determinar um valor de deriva respectivo para cada terminal remoto (112, 114, 116, 118) consultado, em que cada valor de deriva é baseado em uma diferença entre uma referência de temporização inicial e uma referência de temporização subsequente como resultado de uma mudança da posição de um satélite (202) da rede; calcular um valor de atraso de tempo com base em pelo menos um subconjunto dos valores de deriva determinados; monitorar uma rajada de dados recebidos de cada terminal remoto para um erro; transmitir informações de retroalimentação de temporização de circuito fechado (CLT) para a pluralidade de terminais remotos (112, 114, 116, 118) quando o erro cruza um limite, em que a temporização remota é corrigida com base na informação de retroalimentação de temporização de circuito fechado, e em que a informação de retroalimentação de temporização de circuito fechado é baseada no tempo de rajadas de dados recebidos em relação a uma janela de abertura de tempo; o método para sincronização de quadros em um sistema de comunicação por satélite sendo caracterizado pelo fato de que: um sinalizador está contido como um campo em um Pacote de Numeração de Superquadro transmitido para os terminais remotos, em que o sinalizador de status sinaliza para os terminais remotos o mecanismo de temporização de rota de entrada que está sendo utilizado no momento, sendo que: - um sinalizador de status VERDADEIRO sinaliza que um mecanismo de temporização de circuito fechado está sendo usado e correções de tempo são fornecidas para os terminais remotos, e - um sinalizador de status FALSO sinaliza que um mecanismo de cálculo TRO de deslocamento de tempo remoto está sendo usado nos treminais remotos.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende, adicionalmente: determinar um atraso de propagação estimado com base nos valores de deriva determinados; e transmitir o atraso de propagação estimado para cada um dos terminais remotos (112, 114, 116, 118).

3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que compreende, adicionalmente, consultar o um ou mais terminais remotos (112, 114, 116, 118) para obter um valor inicial de atraso de propagação respectivo para cada terminal remoto (112, 114, 116, 118) consultado.

4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que a determinação do atraso de propagação estimado é baseada, adicionalmente, nos valores iniciais de atraso de propagação determinados.

5. Método, de acordo com qualquer uma das reivindicações de 1 a 4, caracterizado pelo fato de que compreende, adicionalmente, obter as coordenadas respectivas de latitude e longitude para cada um dentre os um ou mais terminais remotos consultados.

6. Método, de acordo com qualquer uma das reivindicações de 1 a 5, caracterizado pelo fato de que a consulta do um ou mais terminais remotos(112, 114, 116, 118) compreende consultar o um ou mais terminais remotos com base em uma faixa de valores de atraso de propagação estimados e um limite predeterminado para obter uma seleção geograficamente diversa da pluralidade de terminais remotos(112, 114, 116, 118).

7. Método, de acordo com qualquer uma das reivindicações de 1 a 6, caracterizado pelo fato de que compreende, adicionalmente, realizar um procedimento aloha de reamostragem antes de obter um número predeterminado de valores de deriva a partir dos terminais remotos (112, 114, 116, 118) consultados.

8. Método, de acordo com qualquer uma das reivindicações de 1 a 7, caracterizado pelo fato de que compreende, adicionalmente: transmitir uma mensagem de retroalimentação de correção de temporização de circuito fechado a qualquer terminal remoto (112, 114, 116, 118) que exiba um erro de temporização superior a um montante predeterminado.

9. Aparelho para sincronização de quadros em um sistema de comunicações por satélite, compreendendo: uma porção de comunicações (508, 520); e um módulo de processador configurado para controlar a porção de comunicações (508, 520) para consultar um subconjunto dentre uma pluralidade de terminais remotos (112, 114, 116, 118) de uma rede de comunicações de satélite, e receber uma resposta de pesquisa de cada um dos terminais remotos pesquisados; e em que o módulo de processador é configurado adicionalmente para determinar um valor de deriva respectivo para cada terminal remoto (112, 114, 116, 118) consultado, em que cada valor de deriva é baseado em uma diferença entre uma referência de temporização inicial e uma referência de temporização subsequente como um resultado da mudança de posição de um satélite (202) da rede, calcular um valor de atraso de tempo com base em pelo menos um subconjunto dos valores de deriva determinados; sendo que o aparelho para sincronização de quadros em um sistema de comunicações por satélite monitora uma rajada de dados recebidos de cada terminal remoto para um erro; sendo que o aparelho para sincronização de quadros em um sistema de comunicações por satélite transmite informações de retroalimentação de temporização de circuito fechado (CLT) para a pluralidade de terminais remotos (112, 114, 116, 118) quando o erro cruza um limite, em que a temporização remota é corrigida com base na informação de retroalimentação de temporização de circuito fechado, e em que a informação de retroalimentação de temporização de circuito fechado é baseada no tempo de rajadas de dados recebidos em relação a uma janela de abertura de tempo; o aparelho para sincronização de quadros em um sistema de comunicação por satélite sendo caracterizado pelo fato de que: um sinalizador está contido como um campo em um Pacote de Numeração de Superquadro transmitido para os terminais remotos, em que o sinalizador de status sinaliza para os terminais remotos o mecanismo de temporização de rota de entrada que está sendo utilizado no momento, sendo que: - um sinalizador de status VERDADEIRO sinaliza que um mecanismo de temporização de circuito fechado está sendo usado e correções de tempo são fornecidas para os terminais remotos, e - um sinalizador de status FALSO sinaliza que um mecanismo de cálculo TRO de deslocamento de tempo remoto está sendo usado nos treminais remotos.

10. Aparelho, de acordo com a reivindicação 9, caracterizado pelo fato de que o módulo de processador é configurado, adicionalmente, para determinar um atraso de propagação estimado com base em valores de deriva obtidos, e para controlar a porção de comunicações (508, 520) para transmitir o atraso de propagação estimado a cada um dos terminais remotos (112, 114, 116, 118).

11. Aparelho, de acordo com a reivindicação 10, caracterizado pelo fato de que o módulo de processador é configurado, adicionalmente, para controlar a porção de comunicações (508, 520) para consultar o um ou mais terminais remotos para obter um valor inicial de atraso de propagação respectivo para cada terminal remoto consultado (112, 114, 116, 118).

12. Aparelho, de acordo com a reivindicação 11, caracterizado pelo fato de que a determinação do atraso de propagação estimado é baseada, adicionalmente, nos valores iniciais de atraso de propagação determinados.

13. Aparelho, de acordo com qualquer uma das reivindicações de 9 a 12, caracterizado pelo fato de que o módulo de processador é configurado, adicionalmente, para controlar a porção de comunicações (508, 520) para receber as coordenadas respectivas de latitude e longitude para cada um dentre o um ou mais terminais remotos consultados.

14. Aparelho, de acordo com qualquer uma das reivindicações de 9 a 13, caracterizado pelo fato de que a consulta do um ou mais terminais remotos é baseada em uma faixa de valores de atraso de propagação estimados e um limite predeterminado para obter uma seleção geograficamente diversa da pluralidade de terminais remotos.

15. Aparelho, de acordo com qualquer uma das reivindicações de 9 a 14, caracterizado pelo fato de que o módulo de processador é configurado, adicionalmente, para controlar o aparelho para realizar um procedimento aloha de reamostragem através da porção de comunicações antes de obter um número predeterminado de valores de deriva a partir dos terminais remotos (112, 114, 116, 118) consultados.

16. Aparelho, de acordo com qualquer uma das reivindicações de 9 a 15, caracterizado pelo fato de que o módulo de processador é configurado, adicionalmente, para controlar a porção de comunicações (508, 520) para transmitir uma mensagem de retroalimentação de correção de temporização de volta fechada a qualquer terminal remoto (112, 114, 116, 118) que exiba um erro de temporização superior a um montante predeterminado.