BRPI0722400A2 - protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó - Google Patents
protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó Download PDFInfo
- Publication number
- BRPI0722400A2 BRPI0722400A2 BRPI0722400-1A BRPI0722400A BRPI0722400A2 BR PI0722400 A2 BRPI0722400 A2 BR PI0722400A2 BR PI0722400 A BRPI0722400 A BR PI0722400A BR PI0722400 A2 BRPI0722400 A2 BR PI0722400A2
- Authority
- BR
- Brazil
- Prior art keywords
- node device
- parent
- devices
- node
- node devices
- Prior art date
Links
- 238000005259 measurement Methods 0.000 title abstract description 25
- 230000003044 adaptive effect Effects 0.000 claims abstract description 15
- 238000000034 method Methods 0.000 claims description 232
- 230000006854 communication Effects 0.000 claims description 228
- 238000004891 communication Methods 0.000 claims description 228
- 230000005540 biological transmission Effects 0.000 claims description 133
- 230000001360 synchronised effect Effects 0.000 claims description 86
- 238000012544 monitoring process Methods 0.000 claims description 21
- 238000012790 confirmation Methods 0.000 claims description 17
- 239000013078 crystal Substances 0.000 abstract description 45
- 230000007246 mechanism Effects 0.000 abstract description 21
- 238000005516 engineering process Methods 0.000 abstract description 18
- 230000005611 electricity Effects 0.000 abstract description 16
- 238000009826 distribution Methods 0.000 abstract description 12
- 238000002955 isolation Methods 0.000 abstract description 11
- 230000007613 environmental effect Effects 0.000 abstract description 10
- 238000005457 optimization Methods 0.000 abstract description 8
- 230000008093 supporting effect Effects 0.000 abstract description 5
- 238000003780 insertion Methods 0.000 abstract description 3
- 230000037431 insertion Effects 0.000 abstract description 3
- 108091006146 Channels Proteins 0.000 description 164
- 230000008569 process Effects 0.000 description 109
- 239000003795 chemical substances by application Substances 0.000 description 53
- 238000007726 management method Methods 0.000 description 50
- 230000004044 response Effects 0.000 description 46
- 230000006870 function Effects 0.000 description 42
- 238000004422 calculation algorithm Methods 0.000 description 41
- 238000012546 transfer Methods 0.000 description 35
- 230000000875 corresponding effect Effects 0.000 description 32
- 238000012937 correction Methods 0.000 description 30
- 230000008859 change Effects 0.000 description 25
- 238000005311 autocorrelation function Methods 0.000 description 24
- 238000013459 approach Methods 0.000 description 23
- 230000007175 bidirectional communication Effects 0.000 description 22
- 238000004458 analytical method Methods 0.000 description 18
- 230000033228 biological regulation Effects 0.000 description 17
- 230000008901 benefit Effects 0.000 description 15
- 238000009792 diffusion process Methods 0.000 description 15
- 239000000872 buffer Substances 0.000 description 14
- 238000000605 extraction Methods 0.000 description 13
- 238000001514 detection method Methods 0.000 description 12
- 238000007792 addition Methods 0.000 description 11
- 238000004364 calculation method Methods 0.000 description 11
- 235000008694 Humulus lupulus Nutrition 0.000 description 10
- 230000009471 action Effects 0.000 description 10
- 230000004913 activation Effects 0.000 description 10
- 230000007423 decrease Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 9
- 230000000694 effects Effects 0.000 description 9
- 230000001965 increasing effect Effects 0.000 description 9
- 238000001228 spectrum Methods 0.000 description 9
- 238000012545 processing Methods 0.000 description 8
- 238000013475 authorization Methods 0.000 description 7
- 230000001934 delay Effects 0.000 description 7
- 230000001976 improved effect Effects 0.000 description 7
- 230000000737 periodic effect Effects 0.000 description 7
- 125000004122 cyclic group Chemical group 0.000 description 6
- 238000003891 environmental analysis Methods 0.000 description 6
- 230000036039 immunity Effects 0.000 description 6
- 238000009434 installation Methods 0.000 description 6
- 238000003860 storage Methods 0.000 description 6
- 238000012935 Averaging Methods 0.000 description 5
- 101100508818 Mus musculus Inpp5k gene Proteins 0.000 description 5
- 101100366438 Rattus norvegicus Sphkap gene Proteins 0.000 description 5
- 238000006243 chemical reaction Methods 0.000 description 5
- 230000001276 controlling effect Effects 0.000 description 5
- 238000013075 data extraction Methods 0.000 description 5
- 230000003111 delayed effect Effects 0.000 description 5
- 238000013461 design Methods 0.000 description 5
- 238000013467 fragmentation Methods 0.000 description 5
- 238000006062 fragmentation reaction Methods 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 208000011580 syndromic disease Diseases 0.000 description 5
- 230000003612 virological effect Effects 0.000 description 5
- 230000006399 behavior Effects 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 4
- 238000005562 fading Methods 0.000 description 4
- 238000001914 filtration Methods 0.000 description 4
- 239000012634 fragment Substances 0.000 description 4
- 230000010354 integration Effects 0.000 description 4
- 238000011084 recovery Methods 0.000 description 4
- 230000001105 regulatory effect Effects 0.000 description 4
- 239000000523 sample Substances 0.000 description 4
- 239000000758 substrate Substances 0.000 description 4
- 206010033799 Paralysis Diseases 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 230000000644 propagated effect Effects 0.000 description 3
- 230000035945 sensitivity Effects 0.000 description 3
- 238000012384 transportation and delivery Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000001133 acceleration Effects 0.000 description 2
- 230000032683 aging Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 2
- 239000004566 building material Substances 0.000 description 2
- 238000012512 characterization method Methods 0.000 description 2
- 238000013016 damping Methods 0.000 description 2
- 238000013523 data management Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 238000005304 joining Methods 0.000 description 2
- 230000009191 jumping Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000000116 mitigating effect Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 230000003252 repetitive effect Effects 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 238000007619 statistical method Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000011144 upstream manufacturing Methods 0.000 description 2
- PCTMTFRHKVHKIS-BMFZQQSSSA-N (1s,3r,4e,6e,8e,10e,12e,14e,16e,18s,19r,20r,21s,25r,27r,30r,31r,33s,35r,37s,38r)-3-[(2r,3s,4s,5s,6r)-4-amino-3,5-dihydroxy-6-methyloxan-2-yl]oxy-19,25,27,30,31,33,35,37-octahydroxy-18,20,21-trimethyl-23-oxo-22,39-dioxabicyclo[33.3.1]nonatriaconta-4,6,8,10 Chemical compound C1C=C2C[C@@H](OS(O)(=O)=O)CC[C@]2(C)[C@@H]2[C@@H]1[C@@H]1CC[C@H]([C@H](C)CCCC(C)C)[C@@]1(C)CC2.O[C@H]1[C@@H](N)[C@H](O)[C@@H](C)O[C@H]1O[C@H]1/C=C/C=C/C=C/C=C/C=C/C=C/C=C/[C@H](C)[C@@H](O)[C@@H](C)[C@H](C)OC(=O)C[C@H](O)C[C@H](O)CC[C@@H](O)[C@H](O)C[C@H](O)C[C@](O)(C[C@H](O)[C@H]2C(O)=O)O[C@H]2C1 PCTMTFRHKVHKIS-BMFZQQSSSA-N 0.000 description 1
- 102100039246 Elongator complex protein 1 Human genes 0.000 description 1
- 101710167754 Elongator complex protein 1 Proteins 0.000 description 1
- 108700026140 MAC combination Proteins 0.000 description 1
- 230000004308 accommodation Effects 0.000 description 1
- 239000000654 additive Substances 0.000 description 1
- 230000000996 additive effect Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 239000011230 binding agent Substances 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000012508 change request Methods 0.000 description 1
- 238000001816 cooling Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000001351 cycling effect Effects 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000013499 data model Methods 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 239000006185 dispersion Substances 0.000 description 1
- 238000005553 drilling Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 230000008713 feedback mechanism Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 235000013372 meat Nutrition 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 230000037452 priming Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000001902 propagating effect Effects 0.000 description 1
- 230000008929 regeneration Effects 0.000 description 1
- 238000011069 regeneration method Methods 0.000 description 1
- 230000008844 regulatory mechanism Effects 0.000 description 1
- 238000004353 relayed correlation spectroscopy Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000009420 retrofitting Methods 0.000 description 1
- 230000000630 rising effect Effects 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
- 235000008113 selfheal Nutrition 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 230000007480 spreading Effects 0.000 description 1
- 238000003892 spreading Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Classifications
-
- G—PHYSICS
- G08—SIGNALLING
- G08C—TRANSMISSION SYSTEMS FOR MEASURED VALUES, CONTROL OR SIMILAR SIGNALS
- G08C19/00—Electric signal transmission systems
- G08C19/16—Electric signal transmission systems in which transmission is by pulses
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01D—MEASURING NOT SPECIALLY ADAPTED FOR A SPECIFIC VARIABLE; ARRANGEMENTS FOR MEASURING TWO OR MORE VARIABLES NOT COVERED IN A SINGLE OTHER SUBCLASS; TARIFF METERING APPARATUS; MEASURING OR TESTING NOT OTHERWISE PROVIDED FOR
- G01D4/00—Tariff metering apparatus
- G01D4/002—Remote reading of utility meters
- G01D4/004—Remote reading of utility meters to a fixed location
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01D—MEASURING NOT SPECIALLY ADAPTED FOR A SPECIFIC VARIABLE; ARRANGEMENTS FOR MEASURING TWO OR MORE VARIABLES NOT COVERED IN A SINGLE OTHER SUBCLASS; TARIFF METERING APPARATUS; MEASURING OR TESTING NOT OTHERWISE PROVIDED FOR
- G01D4/00—Tariff metering apparatus
- G01D4/002—Remote reading of utility meters
- G01D4/006—Remote reading of utility meters to a non-fixed location, i.e. mobile location
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
- H04B1/69—Spread spectrum techniques
- H04B1/713—Spread spectrum techniques using frequency hopping
- H04B1/7143—Arrangements for generation of hop patterns
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B17/00—Monitoring; Testing
- H04B17/30—Monitoring; Testing of propagation channels
- H04B17/309—Measuring or estimating channel quality parameters
- H04B17/318—Received signal strength
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/14—Relay systems
- H04B7/15—Active relay systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/12—Shortest path evaluation
- H04L45/127—Shortest path evaluation based on intermediate node capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/005—Routing actions in the presence of nodes in sleep or doze mode
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
- H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
- H04W40/248—Connectivity information update
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W56/00—Synchronisation arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W56/00—Synchronisation arrangements
- H04W56/001—Synchronization between nodes
- H04W56/0015—Synchronization between nodes one node acting as a reference for the others
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W56/00—Synchronisation arrangements
- H04W56/001—Synchronization between nodes
- H04W56/002—Mutual synchronization
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/005—Discovery of network devices, e.g. terminals
-
- H—ELECTRICITY
- H10—SEMICONDUCTOR DEVICES; ELECTRIC SOLID-STATE DEVICES NOT OTHERWISE PROVIDED FOR
- H10N—ELECTRIC SOLID-STATE DEVICES NOT OTHERWISE PROVIDED FOR
- H10N70/00—Solid-state devices without a potential-jump barrier or surface barrier, and specially adapted for rectifying, amplifying, oscillating or switching
- H10N70/801—Constructional details of multistable switching devices
- H10N70/841—Electrodes
- H10N70/8418—Electrodes adapted for focusing electric field or current, e.g. tip-shaped
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
- H04W40/04—Communication route or path selection, e.g. power-based or shortest path routing based on wireless node resources
- H04W40/10—Communication route or path selection, e.g. power-based or shortest path routing based on wireless node resources based on available power or energy
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
- H04W48/12—Access restriction or access information delivery, e.g. discovery data delivery using downlink control channel
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02B—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO BUILDINGS, e.g. HOUSING, HOUSE APPLIANCES OR RELATED END-USER APPLICATIONS
- Y02B90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
- Y02B90/20—Smart grids as enabling technology in buildings sector
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
- Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
- Y04S20/00—Management or operation of end-user stationary applications or the last stages of power distribution; Controlling, monitoring or operating thereof
- Y04S20/30—Smart metering, e.g. specially adapted for remote reading
Abstract
<B>PROTOCOLO DE LAN DE RF DE MEDIçAO E UTILIZAçAO E GERENCIAMENTO DE CELULA / NO <D>A presente tecnologia se refere a protocolos relativos a medidores de serviços de utilidade pública associados a uma estrutura operacional aberta. Mais par, o presente assunto se refere a um assunto de protocolo para uma infra- estrutura de medição avançada, adaptável para vários padrões internacionais, enquanto suporta de forma económica uma solução de rede de malha de 2 vias em um ambiente sem fio, tal como para operação em um campo de medidor de eletricidade residencial. O presente assunto suporta medidores em um sistema de C12.22/C12.19 de padrão ANSI, enquanto suporta de forma económica uma solução de rede de malha de 2 vias em um ambiente sem fio, tal como para operação em um campo de medidor de eletricidade residencial, tudo para permitir uma inserção adaptativa baseada em célula de medidores C12.22 em uma estrutura aberta. Um isolamento de célula é provido através de seqúências quase ortogonais em uma rede de salto defreqúência. Recursos adicionais se referem a uma distribuição de relógio em tempo real e uma recuperação, um roteamento de enlace ascendente sem se requerer uma tabela de roteamento, e a manipulação de Requisições de Sinal de Orientação e resolução de bit de Estado Registrado paraevitação de rotas circulares. Os recursos referentes a utilização de célula ou nó ou gerenciamento em uma rede de malha incluem gerenciamento de tamanho de célula, gerenciamento de Número de filhos, compensação de diferença entre a leitura atual e uma de referência de cristal em uma rede de malha, recursos de reconhecimento de difusão, e Controle de Carga de Tráfego em uma Rede de Malha. Outros recursos se referem a recursos de ferramenta de avaliação ambiental para medição da necessidade de desempenho de transceptores de RF, mecanismos de roteamento de enlace descendente, recursos de sistema de notificação de falta de suprimento, o uso de um percurso de atraso de propagação mínimo para otimização da rede de malha, e operação no nível de nó de uma Fase de Descoberta em uma rede de salto de freqúência.
Description
PROTOCOLO DE LAN DE RF DE MEDIÇÃO E UTILIZAÇAO E GERENCIAMENTO DE CÉLULA / NÓ
"Pedido Dividido do PI 0716887-0 de 14/09/2007" REIVINDICAÇÕES DE PRIORIDADE
Este pedido reivindica o benefício do Pedido de Patente U.S. previamente depositado intitulado "METERING RF LAN PROTOCOL AND CELL/NODE UTILIZATION AND MANAGEMENT", USSN respectivamente atribuído 60/845.056, conforme depositado em 15 de setembro de 2006, e USSN atribuído 60/845.994, conforme depositado em 20 de setembro de 2006, os quais são incorporados aqui como referência em suas totalidades para todas as finalidades.
CAMPO DA INVENÇÃO
A presente tecnologia se refere a protocolos para medidores de serviço de utilidade pública associados a uma estrutura operacional aberta. Mais particularmente, o presente assunto se refere a um assunto de protocolo para uma infra- estrutura de medição avançada, adaptável a vários padrões internacionais, enquanto suporta economicamente umã solução de rede de malha de 2 vias em um ambiente sem fio, tal como para operação em um campo de medidor de eletricidade residencial.
ANTECEDENTES DA INVENÇÃO
O objetivo geral da metrologia é monitorar um ou mais fenômenos físicos selecionados para se permitir um registro de eventos monitorados. Essa finalidade básica de metrologia pode ser aplicada a uma variedade de dispositivos de medição usados em vários contextos. Uma área ampla de medição se refere, por exemplo, a medidores de serviço de utilidade pública. Esse papel pode incluir, especificamente, nesse contexto, a monitoração do consumo ou da produção de uma variedade de formas de energia ou outros bens de consumo, por exemplo, incluindo, mas não limitando, eletricidade, água, gás ou óleo.
Mais particularmente, concernindo a medidores de eletricidade, as formas mecânicas de registradores têm sido usadas historicamente para a extração de dados de consumo acumulado de eletricidade. Uma abordagem como essa provia um dispositivo de campo relativamente confiável, especialmente para a tarefa básica ou de nível relativamente mais baixo de simplesmente monitorar o consumo acumulado em quilowatt-hora.
A forma mecânica básica precedente de registrador tipicamente era limitada no seu modo de saída, de modo que apenas uma função de metrologia muito básica ou de nível mais baixo era obtida. Subseqüentemente, formas eletrônicas de dispositivos de metrologia começaram a ser introduzidas, para se permitirem níveis relativamente mais altos de monitoração, envolvendo formas e modos de dados diferentes.
No contexto de medidores de eletricidade especificamente, para uma variedade de finalidades de gerenciamento e de tributação, tornou-se desejável obter dados de uso além das leituras básicas de consumo de quilowatt-hora disponíveis com muitos medidores de eletricidade. Por exemplo, dados desejados adicionais incluíam a taxa de consumo de eletricidade, ou a data e a hora de consumo (os assim denominados dados de "tempo de uso"). Dispositivos de estado sólido providos em placas de circuito impresso, por exemplo, utilizando componentes de circuito integrado programáveis, proveram ferramentas efetivas para a implementação de muitas dessas funções de monitoração de nível mais alto desejadas no contexto de medidor de eletricidade.
Além da introdução benéfica de formas eletrônicas de metrologia, uma variedade de registradores eletrônicos foi introduzida com certas vantagens. Mais ainda, outras formas de saída de dados foram introduzidas e são benéficas para certas aplicações, incluindo transmissões com fio, uma saída de dados através de transmissão por freqüência de rádio, saída em pulso de dados, e via de conexão por linha telefônica, tais como modems ou enlaces celulares.
O advento dessa variedade e de alternativas freqüentemente requereu que as companhias de serviço de utilidade pública fizessem escolhas quanto a quais tecnologias utilizar. Essas escolhas de tempos em tempos eram feitas com base em pontos filosóficos e preferências e/ou com base em pontos práticos, tais como treinamento e familiaridade do pessoal de campo com projetos específicos.
Um outro aspecto do progresso da tecnologia nessa área de metrologia é que vários arranjos de retroajuste foram instituídos. Por exemplo, algumas tentativas foram feitas para a provisão de dispositivos de medição com recursos mais avançados selecionados, sem se ter que mudar completamente ou substituir o medidor básico no campo. Por exemplo, foram feitas tentativas de equipar um dispositivo de medição basicamente mecânico com uma saída eletrônica de dados, tal como para facilitar ligações de telemetria por rádio.
Um outro aspecto da indústria de medidor de eletricidade é que as companhias de serviço de utilidade pública têm exigências de larga escala, às vezes envolvendo literalmente centenas de milhares de instalações de medidor individuais, ou pontos de dados. A implementação de mudanças em incrementos na tecnologia, tal como um retroajuste de novos recursos em um equipamento existente, ou uma tentativa de implementação de mudanças em componentes básicos os quais tornam vários componentes não intercambiáveis com outras configurações já no campo pode gerar problemas consideráveis na indústria.
Os medidores de eletricidade tipicamente incluem um circuito de entrada para o recebimento de sinais de voltagem e de corrente no serviço elétrico. Um circuito de entrada de qualquer tipo ou projeto especifico para o recebimento dos sinais de corrente de serviço elétrico é referido aqui geralmente como um circuito de aquisição de corrente, enquanto um circuito de qualquer tipo ou projeto para o recebimento dos sinais de voltagem de serviço elétrico é referido aqui geralmente como um circuito de aquisição de voltagem.
Um circuito de entrada de medidor de eletricidade pode ser provido com capacidades de monitoração de uma ou mais fases, dependendo de a monitoração ser para ser provida em um ambiente mono ou multifásico. Mais ainda, é desejável que um circuito configurável seletivamente possa ser provido, de modo a se permitir a provisão de serviços novos, alternativos ou atualizados ou o processamento de capacidades em um dispositivo de medição existente. Essas variações nos ambientes ou nas capacidades de monitoração desejados, contudo, levam à exigência que várias configurações de metrologia diferentes sejam divisadas para a acomodação do número de fases requeridas ou desejadas a serem monitoradas ou para a provisão de uma capacidade de processamento alternativa, adicional ou atualizada em um medidor de serviço de utilidade pública.
Mais recentemente, um novo protocolo da ANSI, o ANSI C12.22 está sendo desenvolvido, que pode ser usado para se permitir a abertura de comunicações de protocolo dentre dispositivos de metrologia a partir de vários fabricantes. C12.22 é a designação da última subclasse da família C12.xx da ANSI de normas de Comunicação e Dados de Medidor presentemente sob desenvolvimento. As normas presentemente definidas incluem a ANSI C12.18 relativa a especificações de protocolo para portas óticas do Tipo 2; a ANSI C12 . 19 relativa a definições de Tabela de Dados de Medidor da Indústria de Serviço de Utilidade Pública; e a ANSI C12.21 relativa a um transporte de Serviço de Telefonia Antigo Simples (POTS) de definição de Tabelas de Dados de C12.19. Deve ser apreciado que, embora o restante da discussão possa descrever o C12.22 como um protocolo padrão, pelo menos no momento do depósito do presente pedido, esse protocolo ainda está sendo desenvolvido, de modo que a presente exposição na realidade é pretendida para a descrição de um protocolo aberto, que pode ser usado como um protocolo de comunicações para uma metrologia em rede e é referido para fins de discussão como a norma C12.22 ou o protocolo C12.22.
O C12.22 é um protocolo de camada de aplicativo que provê o transporte de tabelas de dados de C12.19 por qualquer meio de rede. Os padrões atuais para o protocolo C12.22 incluem: recursos de autenticação e de encriptação; metodologia de endereçamento provendo identificadores únicos para entidades corporativas, de comunicação e de dispositivo final; modelos de dados de autodescrição; e roteamento de mensagem por redes heterogêneas.
Muito como um protocolo HTTP prove uma camada de aplicativo comum para navegadores da web, o C12.22 provê uma camada de aplicativo comum para dispositivos de medição. Os benefícios do uso de um padrão como esse incluem a provisão de: uma metodologia para comunicações de sessão e sem sessão; encriptação de dados comuns e segurança; um mecanismo de endereçamento comum para uso por meios de rede proprietários e não proprietários; interoperabilidade dentre dispositivos de medição em um ambiente de comunicação comum; uma integração do sistema com dispositivos de terceiros através de interfaces comuns e abstração de gateway; comunicações de 2 vias e de 1 via com dispositivos finais; e segurança melhorada, confiabilidade e velocidade para a transferência de dados de medição por redes heterogêneas.
Para entendimento da razão pela qual os serviços de utilidade pública estão intensamente interessados em comunicações de protocolo aberto, considere o processo e a facilidade de envio de e-mails a partir de um computador laptop ou de um smartphone. Os provedores de Internet dependem do uso de protocolos abertos para a provisão de um serviço de e-mail. Os e-mails são enviados e recebidos desde que os endereços de e-mail sejam válidos, as caixas de correio não estejam cheias, e os percursos de comunicação estejam funcionais. A maioria dos usuários de e-mail tem a opção de escolher dentre vários provedores de Internet e várias tecnologias, de discada a celular a de banda larga, dependendo principalmente do custo, da velocidade e da mobilidade. Os endereços de e-mail estão em um formato comum, e os protocolos pedem que o e-mail seja portado por portadoras de comunicação sem mudança do e- mail. O protocolo aberto apresentado na norma da ANSI C12.22 provê a mesma oportunidade para comunicações de medidor por redes.
Além disso, o desejo de capacidades de processamento aumentadas, bem como outras considerações, incluindo, mas não limitando, um desejo de prover capacidades melhoradas para componentes de metrologia individuais em uma estrutura operacional aberta, leva a exigências para a criação de uma interface de tais componentes com aplicativos de sistema.
Como tal, é desejado prover um protocolo melhorado para aplicações de infra-estrutura de medição avançada em uma estrutura operacional aberta.
Embora vários aspectos e modalidades alternativas possam ser conhecidos no campo de medição de serviço de utilidade pública, nenhum projeto emergiu que geralmente envolva as características referenciadas acima e outros recursos desejáveis associados à tecnologia de medição de serviço de utilidade pública, conforme apresentado aqui.
SUMÁRIO DA INVENÇÃO
Tendo em vista os recursos reconhecidos encontrados na técnica anterior e endereçados pelo presente assunto, um aparelho melhorado e uma metodologia permitindo uma infra- estrutura de medição avançada em uma estrutura operacional aberta foram providos.
Em um arranjo de exemplo, uma metodologia e o aparelho correspondente foram providos para se permitir uma transmissão de uma informação entre um medidor de serviço de utilidade pública e um aplicativo operacional através de uma rede de salto de freqüência operada de acordo com o presente assunto de protocolo.
Em uma de suas formas mais simples, a presente tecnologia prove uma rede e protocolos de medidor melhorados.
Um aspecto positivo do presente assunto é que ele suporta medidores em um sistema C12.22 / C12.19 do padrão ANSI, enquanto se suporta economicamente uma solução de rede de malha de 2 vias em um ambiente sem fio, tal como para operação em um campo de medidor de eletricidade residencial, tudo para se permitir uma inserção adaptativa baseada em célula de medidores de C12.22 em uma estrutura aberta.
Um outro aspecto positivo do presente assunto é que ele provê um isolamento de célula através de seqüências quase ortogonais em uma rede de salto de freqüência. Alguns aspectos positivos adicionais se referem a uma rede operada com o presente assunto de protocolo é relacionada a distribuição e recuperação de relógio de tempo real, sinal de transmissão de roteamento sem requerer uma tabela de roteamento, e manuseando bit llBeacon Requests" e "Registered State" que resolvem para evitar as rotas circulares.
Ainda aspectos positivos adicionais do presente assunto relata a utilização ou gerenciamento de célula ou nó uma rede de malha se referem ao gerenciamento de tamanho de célula, para gerenciamento de número de filhos, para compensação de deriva de cristal em uma rede de malha, para difusão de recursos de reconhecimento, e para controle de carga de tráfego em uma rede de malha.
Aspectos adicionais do presente assunto se referem recursos de ferramenta de avaliação ambiental de RF embutido para calibração da necessidade de performance de transceptores de RF, mecanismos de roteamento de enlace descendente, recursos de sistema de notificação de falha, o uso de um percurso de atraso de propagação mínimo para a otimização de uma rede de malha, e operação no nível de nó de uma fase de descoberta em uma rede de salto de freqüência.
O presente assunto igualmente se refere a uma metodologia, bem como ao assunto de aparelho relacionado, no nível de rede e no nível de dispositivo. Uma modalidade de método de exemplo presente se refere a uma metodologia para a geração de uma seqüência pseudo-randômica para uso em uma rede de salto de freqüência de sistema de medição avançado, compreendendo: o estabelecimento de uma rede incluindo uma instalação central e uma pluralidade de dispositivos finais, pelo menos alguns desses dispositivos finais compreendendo dispositivo de metrologia, e onde cada dispositivo final está associado a uma de uma pluralidade de células, a cada célula sendo atribuído um identificador de célula único; a construção de uma seqüência de salto externa para uma dada célula usando-se o identificador de célula único da dada célula como uma semente; o uso dos elementos da seqüência de salto externa para a seleção de uma seqüência de salto interna de N saltos, onde o inteiro N é o número de canais usados pela rede de salto de freqüência de sistema de medição avançado; e a aplicação da seqüência selecionada como um padrão de salto de transceptor para um dispositivo final selecionado na dada célula.
Uma presente modalidade de aparelho de exemplo se refere a uma rede de salto de freqüência de sistema de medição avançado que compreende: uma instalação central; e uma pluralidade de dispositivos finais, pelo menos alguns desses dispositivos finais compreendendo dispositivo de metrologia, com a referida instalação central e a referida pluralidade de dispositivos finais sendo configurada para comunicações bidirecionais entre eles, e com cada dispositivo final estando associado a uma de uma pluralidade de células, cada uma tendo um identificador de célula único. Preferencialmente, nessa modalidade de exemplo, cada dispositivo final em uma dada célula é configurado para comunicações sincronizadas com cada outro dispositivo final na dada célula. Com um arranjo como esse, vantajosamente as comunicações dentre células adjacentes são substancialmente isoladas; e as comunicações efetuadas por um ou mais dispositivos finais em uma dada célula são efetuadas usando-se um padrão de salto formado a partir de uma combinação alojada de duas seqüências, incluindo uma seqüência interna gerada com aritmética de campo de Galois e uma seqüência externa gerada usando-se o identificador de célula único para a dada célula como uma semente.
Uma outra modalidade de exemplo presente do presente assunto, mais particularmente relativa ao assunto de dispositivo, refere-se a um dispositivo de metrologia para uso com uma rede de salto de freqüência de sistema de medição avançado, esse dispositivo de metrologia caracterizado por um identificador único.
Preferencialmente, esse dispositivo de metrologia de exemplo pode compreender uma porção de metrologia configurada para a medição do consumo de um bem de consumo de serviço de utilidade pública; uma porção de transmissor configurada para a transmissão de uma informação de consumo; e uma porção de receptor configurada para a recepção de uma informação a partir de outros dispositivos de rede. Com esse dispositivo de exemplo, preferencialmente a porção de transmissor e a porção de receptor são configuradas para comunicação usando um padrão de salto de freqüência formado a partir de uma combinação alojada de duas seqüências, incluindo uma seqüência de salto interna gerada com aritmética de campo de Galois e uma seqüência de salto externa gerada usando-se o identificador único para o dispositivo de metrologia como uma semente.
Uma modalidade de exemplo presente se refere a um método para a provisão de uma distribuição de relógio em tempo real em uma rede de malha de sistema de medição avançado. Uma modalidade de exemplo como essa preferencialmente pode compreender o estabelecimento de uma rede que inclui pelo menos um nó de raiz e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia; a configuração da rede para comunicações bidirecionais entre pelo menos um nó de raiz e cada um da pluralidade de dispositivos de nó; o estabelecimento de um hiperquadro tendo um comprimento predeterminado; divisão do hiperquadro em um número predeterminado de intervalos de tempo representado por números de intervalo de tempo variando de zero ao número predeterminado de intervalos de tempo; o estabelecimento de um número de hiperquadro máximo correspondente ao número de vezes que o hiperquadro é para ser repetido em uma seqüência representada pelos números de hiperquadro variando de zero a esse número de hiperquadro máximo; a configuração de pelo menos um nó de raiz para comunicações com um padrão de tempo predeterminado; o incremento repetidamente do número de intervalo de tempo, de modo que o número de intervalo de tempo role passando pelo zero como o próximo número seguindo-se ao número predeterminado de intervalos de tempo; o incremento do número de hiperquadro uma vez seguindo-se a cada rolagem do número de intervalo de tempo, de modo que o número de hiperquadro role passando pelo zero como o próximo número seguindo-se ao número máximo de hiperquadros; e a difusão de uma mensagem incluindo uma estampa de tempo derivada do padrão de tempo predeterminado a partir do nó de raiz até a pluralidade de dispositivos de nó sempre que o número de hiperquadro e o número de intervalo de tempo forem ambos nulos. Com essa metodologia de exemplo, a pluralidade de dispositivos de nó pode ser sincronizada, cada um, com o nó de raiz.
Uma outra modalidade de metodologia de exemplo presente pode se relacionar a um método para a ressincronização de uma informação de relógio em tempo real de uma rede de malha de sistema de medição avançado. Essa metodologia preferencialmente pode compreender o estabelecimento de uma rede incluindo pelo menos um nó de raiz e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia; a configuração da rede para comunicações bidirecionais entre pelo menos um nó de raiz e cada um da pluralidade de dispositivos de nó; a configuração da pluralidade de dispositivos de nó de modo que um ou mais dispositivos de nó correspondam a um ou mais dispositivos de nó filho e um ou mais dispositivos de nó correspondam a dispositivos de nó pai; a associação de cada dispositivo de nó filho a um ou mais dispositivos de nó pai; a transmissão de uma informação de tempo de atualização para cada dispositivo de nó filho a partir de seus um ou mais dispositivos de nó pai associados em um formato de pacote incluindo porções predeterminadas de preâmbulo e de cabeçalho em uma taxa de bit predeterminada; e a configuração de cada dispositivo de nó filho para a ressincronização de si mesmo com base na informação de tempo de atualização transmitida a cada vez que ele receber uma mensagem a partir de um de seus dispositivos de nó pai associados.
Uma outra presente modalidade de exemplo mais particularmente relativa ao presente aparelho ser refere a uma rede de malha de sistema de medição avançado, preferencialmente compreendendo um nó de raiz; e uma pluralidade de dispositivos de nó. Ainda, cada um desses dispositivos de nó preferencialmente é configurado para comunicações baseadas bidirecionais com o nó de raiz, e com pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia. Mais ainda, preferencialmente cada um dessa pluralidade de dispositivos de nó é adicionalmente configurado para a transmissão de respectivas mensagens de pacote, cada mensagem de pacote contendo pelo menos uma porção de preâmbulo e uma porção de cabeçalho. Com o arranjo de exemplo precedente, cada um dessa pluralidade de dispositivos de nó é adicionalmente configurado para operar de acordo com os intervalos de tempo de repetição em hiperquadros de repetição, com cada um dessa pluralidade de dispositivos de nó atribuído um endereço de célula de rede e um número de nível com base no número de saltos de cada respectivo dispositivo de nó a partir do referido nó de raiz, e com cada mensagem de pacote incluindo pelo menos uma indicação do número de nível de dispositivo de nó de transmissão, endereço de célula e intervalo de tempo. Com a prática de uma modalidade de exemplo como essa, a sincronização de todos os dispositivos de nó na rede pode ser mantida.
Um método de exemplo presente se refere a uma metodologia para uma rede de malha de sistema de medição avançado com comunicações de enlace ascendente de auto- otimização. Essa metodologia de exemplo presente pode compreender o estabelecimento de uma rede incluindo uma instalação central e uma pluralidade de dispositivos finais, pelo menos alguns desses dispositivos finais compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos finais compreendem relês de célula os quais provêem comunicações entre outros dos dispositivos finais e a instalação central; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos finais através de associações com respectivos relês de célula; a computação de um atraso de propagação local médio para cada enlace de um salto para comunicações de enlace ascendente a partir de dispositivos finais em direção a seu relê de célula; a computação do atraso de propagação médio global ao longo de cada percurso de enlace ascendente a partir de um dispositivo final para seu relê de célula associado; a seleção em cada dispositivo final do valor mais baixo de atraso de propagação médio global para a definição de seu próprio valor de atraso de propagação global otimizado; e a condução de comunicações de enlace ascendente usando o percurso correspondente ao valor selecionado. Com essa metodologia de exemplo, as comunicações de enlace ascendente a partir dos dispositivos finais com a instalação central são otimizadas sem se requerer um armazenamento de uma tabela de roteamento.
Uma modalidade de aparelho de exemplo presente se refere a uma rede de malha de sistema de medição avançado com comunicações de enlace ascendente de auto-otimização. Essa modalidade de exemplo preferencialmente compreende uma instalação central; e uma pluralidade de dispositivos finais. Ainda, pelo menos alguns desses dispositivos finais preferencialmente compreendem dispositivos de metrologia, enquanto pelo menos alguns desses dispositivos finais compreendem relês de célula os quais provêem comunicações entre outros dos dispositivos finais e a instalação central. Mais ainda,cada dispositivo final preferencialmente é configurado para comunicações bidirecionais com a instalação central através de um relê associado desses relês de célula. Por essa modalidade de exemplo, preferencialmente, cada dispositivo final é configurado para computação de um atraso de propagação local médio para cada enlace de um salto para comunicações de enlace ascendente a partir de si mesmo em direção ao seu relê de célula associado, para computação do atraso de propagação médio global ao longo de cada percurso de enlace ascendente a partir de si mesmo até seu relê de célula associado, para a seletivamente para si mesmo do valor mais baixo de atraso de propagação médio global para a definição de seu próprio valor de atraso de propagação global otimizado e para condução de comunicações de enlace ascendente usando o percurso correspondente ao valor selecionado. Com uma modalidade como essa, as comunicações de enlace ascendente a partir desses dispositivos finais para a instalação central são otimizadas, sem se requerer o armazenamento de uma tabela de roteamento.
Ainda uma outra modalidade de exemplo presente se refere a um dispositivo de metrologia para uso com uma rede de malha de sistema de medição avançado com comunicações de enlace ascendente de auto-otimização, e incluindo uma instalação central, uma pluralidade de dispositivos finais, com pelo menos alguns desses dispositivos finais compreendendo esses dispositivos de metrologia, e pelo menos alguns desses dispositivos finais compreendendo relês de célula os quais provêem comunicações entre outros desses dispositivos finais e a instalação central, com cada dispositivo final configurado para comunicações bidirecionais com essa instalação central através de um relê associado desses relês de célula. Esse dispositivo de metrologia de exemplo presente preferencialmente pode compreender uma porção de metrologia configurada para a medição do consumo de um bem de consumo de serviço de utilidade pública; uma porção de transmissor configurada para a transmissão de uma informação de consumo e outros dados; e uma porção de receptor configurada para receber uma informação a partir de outros dispositivos de rede. Mais ainda, nessa presente modalidade de exemplo, preferencialmente a porção de transmissor e a porção de receptor são configuradas para a computação de um atraso de propagação local médio para cada enlace de um salto para comunicações de enlace ascendente a partir desse dispositivo de metrologia em direção a seu relê de célula associado, para computação do atraso de propagação médio global ao longo de cada percurso de enlace ascendente a partir desse dispositivo de metrologia até seu relê de célula associado, para seleção para si mesmo do valor mais baixo de atraso de propagação médio global para a definição de seu próprio valor de atraso de propagação global otimizado, e para a condução de comunicações de enlace ascendente usando o percurso correspondente ao valor selecionado. Com essa modalidade de exemplo, as comunicações de enlace ascendente a partir desse dispositivo de metrologia para uma instalação central de uma rede de malha de sistema de medição avançado associada são otimizadas, sem se requerer um armazenamento de uma tabela de roteamento de enlace ascendente nesse dispositivo de metrologia.
Uma presente modalidade de exemplo concerne a uma metodologia para um dispositivo final em uma rede de salto de freqüência de sistema de medição avançado para manipulação de uma requisição de sincronização de um outro dispositivo final. Essa presente modalidade de exemplo se refere à provisão de uma rede de salto de freqüência incluindo uma pluralidade de dispositivos finais, pelo menos alguns desses dispositivos finais compreendendo dispositivos de metrologia; a configuração da pluralidade de dispositivos finais para comunicações bidirecionais com outros dispositivos finais; o recebimento de uma requisição de sincronização em um dado dispositivo final a partir de um dispositivo final não sincronizado vizinho; e determinar se o dado dispositivo final recebeu em um número predeterminado de intervalos de tempo recentes uma mensagem a partir de um dispositivo final pai, por meio do que o dado dispositivo final foi sincronizado. Preferencialmente, por essa metodologia, se ele tiver sido, então, um sinal de aceitação de sincronização será transmitido para o dispositivo final não sincronizado requisitante. Caso ele não tenha sido, então, ao invés disso, um sinal de requisição de sinal de orientação é transmitido para um dispositivo final pai registrado.
Uma metodologia de exemplo presente adicional se refere a uma metodologia para permitir que um dispositivo final de rede estabeleça um enlace com uma rede de salto de freqüência de sistema de medição avançado existente. Essa presente modalidade de exemplo preferencialmente pode compreender a provisão de uma sistema de alinhamento de folha incluindo uma instalação central e uma pluralidade de dispositivos finais, pelo menos alguns desses dispositivos finais compreendendo dispositivos de metrologia; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos finais; fazer com que um dispositivo final registrado previamente, o qual perdeu sua sincronização com a rede, transmita uma requisição de sinal de orientação para um dispositivo final vizinho; e a configuração do dispositivo final vizinho para transmitir uma informação de sincronização para o dispositivo final previamente registrado, se o dispositivo final vizinho tiver recebido em um número predeterminado de intervalos de tempo recentes uma mensagem a partir de um dispositivo final pai pelo qual o dispositivo final vizinho foi sincronizado.
Uma presente modalidade de exemplo relativa ao assunto de rede preferencialmente pode incluir uma rede de salto de freqüência de sistema de medição avançado, compreendendo uma instalação central; uma pluralidade de dispositivos finais, pelo menos alguns desses dispositivos finais compreendendo dispositivos de metrologia, com a referida instalação central e a referida pluralidade de dispositivos finais sendo configuradas para comunicações bidirecionais entre si; e pelo menos um dispositivo final capaz de receber uma requisição de sincronização a partir de um dispositivo final vizinho não sincronizado. Ainda, pelo menos um dispositivo final como esse preferencialmente pode ser configurado, mediante o recebimento de uma requisição de sincronização a partir de um dispositivo final vizinho não sincronizado, para determinar se ele recebeu em um número predeterminado de intervalos de tempo recentes uma mensagem a partir de um dispositivo final de nível mais alto por meio do que pelo menos um dispositivo final foi sincronizado. Se assim for, então, preferencialmente, um sinal de aceitação de sincronização é transmitido para o dispositivo final vizinho não sincronizado. Caso não, então, preferencialmente um sinal de requisição de sinal de orientação é transmitido para um dispositivo final de nível mais alto registrado.
Uma presente modalidade de exemplo se refere a uma metodologia para uma rede de malha de sistema de medição avançado com um gerenciamento de vizinhança adaptativo de enlaces de comunicação, compreendendo o estabelecimento de uma rede que inclui uma instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendem dispositivos de nó pai os quais provêem um enlace de comunicações para outros dos dispositivos de nó definindo dispositivos de nó filho de um dado respectivo dispositivo de nó pai; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos de nó através de associações com respectivos dos dispositivos de nó pai; a partir de cada dispositivo de nó filho existente associado a um dado dispositivo de nó pai específico, a provisão de uma informação para esse dado dispositivo de nó pai específico sobre enlaces de comunicações pais alternativos disponíveis para esse dispositivo de nó filho existente; para cada dispositivo de nó pai, mediante o recebimento de uma requisição a partir de um dispositivo de nó não filho para se tornar um dispositivo de nó filho do mesmo, a avaliação dessa informação a partir de seus dispositivos de nó filho existentes e a avaliação de sua capacidade para aceitar um novo dispositivo de nó filho e, se tiver essa capacidade, a aceitação desse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo, ou, caso não tenha essa capacidade, a remoção de seus dispositivos de nó filho existentes de um dispositivo de nó filho existente o qual indicou um enlace de comunicações pai alternativo disponível para ele e, então, a aceitação desse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo.
Uma outra presente modalidade de exemplo mais particularmente se refere a uma metodologia para uma rede de malha de sistema de medição avançado com gerenciamento adaptativo de enlaces de comunicações de pai - filho, compreendendo o estabelecimento de uma rede incluindo uma instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, pelo menos alguns desses dispositivos de nó compreendendo mestres de célula os quais provêem comunicações entre a instalação central e outros dos dispositivos de nó associados a ele em respectivas células formadas por cada respectivo mestre de célula, e pelo menos alguns desses dispositivos de nó compreendendo dispositivos de nó pai os quais provêem um enlace de comunicações sincronizado entre um respectivo mestre de célula e outros dos dispositivos de nó definindo dispositivos de nó filho de um dado respectivo dispositivo de nó pai; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos de nó através de associações com os respectivos dispositivos de nó pai e os mestres de célula; em cada dispositivo de nó, o estabelecimento e a atualização de uma informação sobre cada um desses dispositivos de nó e suas respectivas relações de vizinho e enlaces de comunicações, incluindo uma notificação de indicador tipo de flag confirmando que esse dispositivo de nó tem disponíveis para ele pais potenciais acima de um número predeterminado dos mesmos, cada um desses dispositivos de nó incluindo essa notificação de indicador tipo de flag conforme aplicável em suas transmissões; em cada dispositivo de nó pai, a monitoração dessas notificações de indicador tipo de flag a partir de seus dispositivos de nó filho existentes, e mediante o recebimento de uma requisição de sincronização a partir de um dispositivo de nó não filho quanto a se tornar um dispositivo de nó filho do mesmo, a avaliação dessas notificações de indicador tipo de flag a partir de seus dispositivos de nó filhos existentes e a avaliação de sua capacidade para aceitar um novo dispositivo de nó filho, e se tiver essa capacidade, a sincronização com esse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo, ou se não tiver essa capacidade, a remoção de seus dispositivos de nó filhos existentes de um dispositivo de nó filho existente o qual através de sua notificação de indicador tipo de flag indicou um enlace de comunicação pai alternativo disponível para ele, o envio de uma notificação de remoção para esse dispositivo de nó filho existente sendo removido, e a sincronização com esse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo, por meio do que dispositivos de nó não filhos não são recusados para sincronização na rede.
Ainda uma outra modalidade de exemplo presente está relacionada a uma rede de malha de sem com um gerenciamento de visualização adaptativo de enlaces de comunicações, compreendendo uma instalação central; e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo dispositivos de nó pai os quais provêem um enlace de comunicações para outros desses dispositivos de nó definindo dispositivos de nó filho de um dado respectivo dispositivo de nó pai, com essa rede configurada para comunicações bidirecionais entre essa instalação central e cada um dessa pluralidade de dispositivos de nó através de associações com respectivos desses dispositivos de nó pai. Com uma modalidade de exemplo, preferencialmente cada dispositivo de nó filho existente associado a um dado dispositivo de nó pai especifico é adicionalmente configurado para prover uma informação para esse dado dispositivo de nó pai especifico sobre enlaces de comunicações de pais alternativos disponíveis para esse dispositivo de nó filho existente; cada dispositivo de nó pai ainda é configurado para, mediante o recebimento de uma requisição a partir de um dispositivo de nó não filho, tornar-se um dispositivo de nó filho do mesmo, para avaliação dessa informação a partir de seus dispositivos de nó filho existentes e avaliação de sua capacidade para aceitação de um novo dispositivo de nó filho e, se tiver essa capacidade, a aceitação desse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo ou, caso não tenha essa capacidade, a remoção de seus dispositivos de nó filho existentes de um dispositivo de nó filho existente o qual indicou um enlace de comunicações pai alternativo para ele e, então, a aceitação desse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo.
Ainda uma outra modalidade de exemplo presente se refere a uma rede de malha de sistema de medição avançado com gerenciamento adaptativo de enlaces de comunicações de pai - filho, compreendendo uma instalação central; e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, pelo menos alguns desses dispositivos de nó compreendendo mestres de célula os quais provêem comunicações entre a instalação central e outros dos dispositivos de nó associados a ele em respectivas células formadas por cada respectivo mestre de célula, e pelo menos alguns desses dispositivos de nó compreendendo dispositivos de nó pai os quais provêem um enlace de comunicações sincronizado entre um respectivo mestre de célula e outros dos dispositivos de nó definindo dispositivos de nó filho de um dado respectivo dispositivo de nó pai, com essa rede configurada para comunicações bidirecionais entre essa instalação central e cada um dessa pluralidade de dispositivos de nó através de associações com os respectivos dispositivos de nó pai e os mestres de célula.
Por essa modalidade, preferencialmente, cada dispositivo de nó é configurado para o estabelecimento e a atualização de uma informação sobre cada um desses dispositivos de nó e suas respectivas relações de vizinho e enlaces de comunicações, incluindo uma notificação de indicador tipo de flag confirmando que esse dispositivo de nó tem disponíveis para ele pais potenciais acima de um número predeterminado dos mesmos, e ainda é configurado para incluir essa notificação de indicador tipo de flag conforme aplicável em suas transmissões; cada dispositivo de nó pai ainda é configurado para a monitoração dessas notificações de indicador tipo de flag a partir de seus dispositivos de nó filho existentes, e mediante o recebimento de uma requisição de sincronização a partir de um dispositivo de nó não filho quanto a se tornar um dispositivo de nó filho do mesmo, a avaliação dessas notificações de indicador tipo de flag a partir de seus dispositivos de nó filhos existentes e a avaliação de sua capacidade para aceitar um novo dispositivo de nó filho, e se tiver essa capacidade, a sincronização com esse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo, ou se não tiver essa capacidade, a remoção de seus dispositivos de nó filhos existentes de um dispositivo de nó filho existente o qual através de sua notificação de indicador tipo de flag indicou um enlace de comunicação pai alternativo disponível para ele, o envio de uma notificação de remoção para esse dispositivo de nó filho existente sendo removido, e a sincronização com esse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo, por meio do que dispositivos de nó não filhos não são recusados para sincronização na rede.
Uma modalidade de exemplo adicional presente mais particularmente se refere a um dispositivo de metrologia para uso com uma rede de malha de sistema de medição avançado com gerenciamento de vizinhança adaptativo de enlaces de comunicações e incluindo uma instalação central, uma pluralidade de dispositivos de nó, com pelo menos alguns desses dispositivos de nó compreendendo esses dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo dispositivos de nó pai provendo enlaces de comunicações sincronizados para outros dos dispositivos de nó definindo dispositivos de nó filho de um dado respectivo dispositivo de nó pai, com cada dispositivo de nó configurado para comunicações com essa instalação central através de associações com respectivos dos dispositivos de nó pai. Um dispositivo de metrologia de exemplo como esse preferencialmente pode compreender uma porção de metrologia configurada para a medição do consumo de um bem de consumo de serviço de utilidade pública; uma porção de transmissor configurado para a transmissão de uma informação de consumo e de outros dados; e uma porção de receptor configurada para receber uma informação a partir de outros dispositivos de rede em uma rede associada. Ainda preferencialmente, essas porções de dispositivo de metrologia são configuradas para a provisão para seu respectivo dispositivo de nó pai em uma rede associada de uma informação sobre enlaces de comunicações pais alternativos disponíveis para esse dispositivo de metrologia nessa rede associada, de modo que esse respectivo dispositivo de nó pai possa fazer determinações sobre a remoção desse dispositivo de metrologia como um filho do mesmo no lugar de outros dispositivos de nó nessa rede associada.
Uma presente modalidade de exemplo se refere a um método para a compensação de uma deriva em relógios de dispositivo de nó em uma rede de malha de sistema de medição avançado. Um método de exemplo como esse pode compreender o estabelecimento de uma rede incluindo pelo menos um nó de raiz e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia; a configuração da rede para comunicações bidirecionais dentre pelo menos um nó de raiz e cada um da pluralidade de dispositivos de nó; a provisão de cada dispositivo de nó com um relógio interno controlado por cristal; a condução de comunicações de pacote dentre o nó de raiz e a pluralidade de dispositivos de nó; e a configuração de cada dispositivo de nó para realinhamento de seu relógio interno a cada vez em que o dispositivo de nó se comunicar com um outro dispositivo de nó mais próximo do nó de raiz do que ele mesmo. Por essa metodologia de exemplo, cada um desses dispositivos de nó realinhará seu relógio para estar em sincronização com a rede, desse modo compensando diferenças de tempo causadas pela deriva em qualquer um dos relógios de dispositivo de nó.
Uma outra modalidade de exemplo presente se refere, mais particularmente, a um método para a compensação de uma deriva de freqüência de cristal em uma rede de malha de sistema de medição avançado. Uma metodologia como esse preferencialmente pode compreender o estabelecimento de uma rede incluindo pelo menos um nó de raiz e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia; a configuração da rede para comunicações bidirecionais dentre pelo menos um nó de raiz e cada um da pluralidade de dispositivos de nó; a provisão de cada um da pluralidade de dispositivos de nó com um relógio interno controlado por cristal; a condução de comunicações dentre o nó de raiz e a pluralidade de dispositivos de nó usando-se um hiperquadro de repetição subdividido em um protocolo de pacote de intervalo de tempo de repetição; e a configuração de cada dispositivo de nó para ressincronização de seu relógio interno a cada vez em que o nó se comunicar com o nó de raiz ou com um outro nó mais próximo do que ele mesmo do nó de raiz. Por essa modalidade de exemplo, esse dispositivo de nó realinhará seu relógio interno para estar em sincronização com a rede, desse modo compensando uma deriva de freqüência de cristal.
Ainda uma outra modalidade de exemplo presente se refere a uma rede de malha de sistema de medição avançado que compreende pelo menos um nó de raiz; uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, essa pluralidade de dispositivos de nó configurada para comunicações bidirecionais dentre pelo menos um nó de raiz e outros dessa pluralidade de dispositivos de nó usando-se um hiperquadro de repetição subdividido em um protocolo de pacote de seqüência de intervalo de tempo de repetição; e uma pluralidade de relógios internos controlados por cristal, respectivamente associados a cada um dessa pluralidade de dispositivos de nó. Por essa modalidade de exemplo, preferencialmente cada um desses dispositivos de nó é configurado para ressincronização de seu respectivo relógio interno a cada vez em que esse respectivo dispositivo de nó se comunicar com pelo menos um nó de raiz ou um outro dispositivo de nó mais próximo do que ele mesmo pelo menos desse nó de raiz, por meio do que esse respectivo dispositivo de nó realinhará seu relógio interno para estar em sincronização com a rede. Com essa modalidade, uma deriva de freqüência de cristal é compensada.
Uma presente modalidade de exemplo se refere a um método para a distribuição de uma informação para nós em uma direção de máquina de sistema de medição avançado. Esse método de exemplo pode compreender, preferencialmente, o estabelecimento de uma rede de malha que inclui pelo menos um nó mestre e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia; a configuração da rede para comunicações bidirecionais dentre pelo menos um nó mestre e cada um da pluralidade de dispositivos de nó usando-se um hiperquadro de repetição subdividido em um protocolo de pacote de intervalo de tempo de repetição; a atribuição de níveis a cada nó com base no número de saltos que o nó está distante do nó mestre, de modo que aos nós mais distantes do nó mestre sejam atribuídos números mais altos; a identificação em cada nó de nós vizinhos do mesmo, onde os vizinhos com um nível mais baixo são identificados como os pais do nó, os vizinhos tendo um nível igual são identificados como irmãos, e os vizinhos tendo um nível mais alto são identificados como filhos; a difusão de uma mensagem a partir do nó mestre para os nós de nível mais alto; e a atribuição de seqüências de reconhecimento a nós filhos em mensagens difundidas pelos nós pais. Com essa metodologia, os filhos falhando em receber mensagens difundidas a partir dos pais podem ser identificados.
Uma outra modalidade de exemplo presente se refere, mais particularmente, a um método para a distribuição de informação para nós em uma rede de malha de sistema de medição avançado. Um método de exemplo como esse preferencialmente pode compreender o estabelecimento de uma rede de malha que inclui pelo menos um nó mestre e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia; a configuração da rede para comunicações bidirecionais dentre pelo menos um nó mestre e cada um da pluralidade de dispositivos de nó usando-se um hiperquadro de repetição subdividido em um protocolo de pacote de intervalo de tempo de repetição; a atribuição de níveis a cada nó com base no número de saltos que o nó está distante do nó mestre, de modo que aos nós mais distantes do nó mestre sejam atribuídos números mais altos; a identificação em cada nó de nós vizinhos do mesmo, onde os vizinhos com um nível mais baixo são identificados como os pais do nó, os vizinhos tendo um nível igual são identificados como irmãos, e os vizinhos tendo um nível mais alto são identificados como filhos; a difusão de mensagens a partir de nós pais para nós filhos como seqüências emparelhadas. Vantajosamente, pela prática desse método de exemplo, a primeira mensagem na seqüência emparelhada especifica uma ordem de resposta para nós filhos e a segunda mensagem inclui uma identificação de difusão.
Ainda uma outra modalidade de exemplo presente se refere a uma rede de malha de sistema de medição avançado, que compreende pelo menos um nó mestre; e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, com essa pluralidade de dispositivos de nó configurada para comunicações bidirecionais dentre pelo menos esse dispositivo de metrologia e cada um da pluralidade de dispositivos de nó usando um hiperquadro de repetição subdividido em um protocolo de pacote de intervalo de tempo de repetição. Preferencialmente, por essa modalidade, cada respectivo nó é configurado para ter atribuído um nível com base no número de saltos que o nó está distante de pelo menos esse nó mestre, e para a identificação de nós vizinhos tendo um nível mais baixo como nós pais, vizinhos tendo um nível igual como nós irmãos, e vizinhos tendo um nível mais alto como nós filhos; esses nós pais configurados para a difusão de mensagens para nós filhos como seqüências emparelhadas com uma primeira mensagem especificando uma ordem de resposta para nós filhos e uma segunda mensagem incluindo uma identificação de difusão.
Uma presente modalidade doa metodologia em questão se refere a uma metodologia para uma rede de malha de sistema de medição avançado com um gerenciamento de carga de tráfego de auto-ajuste, compreendendo o estabelecimento de uma rede que inclui uma instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo nós de extração de dados, os quais provêem comunicações pelo menos em uma direção de enlace ascendente entre outros dos dispositivos de nó e a instalação central; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos de nó; a monitoração e o cálculo da respectiva densidade de tráfego em uma direção de enlace ascendente com referência a cada respectivo dispositivo de nó; e o controle do sincronismo das respectivas transmissões em uma direção de enlace ascendente de cada respectivo dispositivo de nó com base em seu respectivo cálculo de densidade de tráfego. Com a prática dessa metodologia, esse cálculo de densidade de tráfego permanece abaixo de um limite de rede predeterminado.
Uma outra metodologia de exemplo presente se refere a uma metodologia para uma rede de malha de salto de freqüência de Aloha com intervalo de sistema de medição avançado com gerenciamento de carga de tráfego de auto- ajuste. Essa modalidade de exemplo preferencialmente compreende o estabelecimento de uma rede incluindo uma instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo dispositivos de nó pai, os quais provêem comunicações pelo menos em uma direção de enlace ascendente entre outros dos dispositivos de nó e a instalação central; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos de nó através de associações com respectivos dispositivos de nó pai; a determinação de uma taxa de sucesso de comunicação média para cada dispositivo de nó pai com referência a cada respectivo dispositivo de nó e a observação de reconhecimentos de comunicações a partir desse dispositivo de nó pai com referência a esse respectivo dispositivo de nó; o controle do sincronismo de respectivas transmissões em uma direção de enlace ascendente de cada respectivo dispositivo de nó com base em seu respectivo cálculo de densidade de tráfego, de modo que esse cálculo de densidade de tráfego permaneça abaixo de um limite de rede predeterminado, com transmissões de enlace ascendente enviadas em um tempo randômico em uma janela de randomização, cujo comprimento Tw de janela de randomização se adéqua à relação a seguir:
<formula>formula see original document page 34</formula>
onde Tw é expresso em unidades de intervalo de tempo, Ra é a densidade de tráfego para um dado dispositivo de nó pai A, e Rmax é uma densidade de entrada de tráfego máxima predeterminada para esse dispositivo de nó pai A; e o armazenamento em buffer de transmissões de enlace ascendente em cada respectivo dispositivo de nó até uma transmissão controlada do mesmo.
Uma outra modalidade de exemplo presente se refere, mais particularmente, a uma rede de malha de sistema de medição avançado com gerenciamento de carga de tráfego de auto-ajuste. Essa modalidade de exemplo pode compreender uma instalação central; e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo nós de extração de dados, os quais provêem comunicações pelo menos em uma direção de enlace ascendente entre outros desses dispositivos de nó e a instalação central, com cada dispositivo de nó configurado para comunicações bidirecionais com essa instalação central. Nessa modalidade de exemplo, preferencialmente cada um desses dispositivos de nó é configurado para a monitoração e o cálculo da respectiva densidade de tráfego em uma direção de enlace ascendente com referência a cada respectivo dispositivo de nó, e para controle do sincronismo de respectivas transmissões em uma direção de enlace ascendente de cada respectivo dispositivo de nó com base em seu respectivo cálculo de densidade de tráfego, de modo que esse cálculo de densidade de tráfego permaneça abaixo de um limite de rede predeterminado.
Ainda uma outra modalidade de exemplo presente se refere a uma rede de malha de salto de freqüência de Aloha com intervalo de sistema de medição avançado com gerenciamento de carga de tráfego de auto-ajuste. Essa modalidade de exemplo preferencialmente pode compreender uma instalação central; e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendem dispositivos de nó pai os quais provêem comunicações pelo menos em uma direção de enlace ascendente entre outros desses dispositivos de nó e a instalação central, com essa rede configurada para comunicações bidirecionais entre essa instalação central e cada um dessa pluralidade de dispositivos de nó através de associações com respectivos desses dispositivos de nó pai. Preferencialmente, cada um desses dispositivos de nó é configurado para a determinação de uma taxa de sucesso de comunicação média para cada dispositivo de nó pai com referência a cada respectivo dispositivo de nó e a observação de reconhecimentos de comunicações a partir desse dispositivo de nó pai e, com base nisso, o cálculo da respectiva densidade de tráfego de cada um desses dispositivos de nó pai co referência a cada um desses respectivos dispositivos de nó; e para controle do sincronismo de respectivas transmissões em uma direção de enlace ascendente de cada respectivo dispositivo de nó com base em seu respectivo cálculo de densidade de tráfego, de modo que esse cálculo de densidade de tráfego permaneça abaixo de um limite de rede predeterminado, com transmissões de enlace ascendente enviadas em um tempo randômico em uma janela de randomização, cujo comprimento Tw de janela de randomização se adéqua à relação a seguir:
<formula>formula see original document page 36</formula>
onde Tw é expresso em unidades de intervalo de tempo, Ra é a densidade de tráfego para um dado dispositivo de nó pai A, e Rmax é uma densidade de entrada de tráfego máxima predeterminada para esse dispositivo de nó pai A; e para o armazenamento em buffer de transmissões de enlace ascendente em cada respectivo dispositivo de nó até uma transmissão controlada disso.
Ainda uma outra modalidade de exemplo presente se refere, mais particularmente, a um dispositivo de metrologia para uso com uma rede de malha de salto de freqüência de Aloha com intervalo de sistema de medição avançado com gerenciamento de carga de tráfego de auto- ajuste, e incluindo uma instalação central, uma pluralidade de dispositivos de nó, com pelo menos alguns desses dispositivos de nó compreendendo dispositivos de nó pai os quais provêem comunicações pelo menos em uma direção de enlace ascendente entre outros dos dispositivos de nó e a instalação central, com cada dispositivo de nó configurado para comunicações bidirecionais com essa instalação central através de pelo menos um desses dispositivos de nó pai associados. Esse dispositivo de metrologia de exemplo preferencialmente pode compreender uma porção de metrologia configurada para a medição do consumo de um bem de consumo de serviço de utilidade pública; uma porção de transmissor configurada para a transmissão de uma informação de consumo e de outros dados; e uma porção de receptor configurada para receber uma informação de outros dispositivos de rede em uma rede associada. Ainda, essa porção de transmissor e essa porção de receptor preferencialmente são configuradas para a monitoração e o cálculo da respectiva densidade de tráfego em uma direção de enlace ascendente a partir dali em uma rede associada e para controle do sincronismo de respectivas transmissões em uma direção de enlace ascendente a partir dali, com base nesse cálculo de densidade de tráfego. Com essa modalidade de exemplo, esse cálculo de densidade de tráfego permanece abaixo de um limite predeterminado de uma rede associada.
Uma modalidade de exemplo da presente metodologia se refere a uma metodologia para uma rede de malha de sistema de medição avançado com ferramentas de avaliação ambiental de RF embutidas. Essa metodologia preferencialmente pode compreender o estabelecimento de uma rede que inclui uma instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo relês de célula os quais provêem comunicações entre outros dos dispositivos de nó e a instalação central; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos de nó; a monitoração seletiva de dados de Indicador de Intensidade de Sinal Recebido (RSSI) em cada respectivo dispositivo de nó; e o relatório desses dados de RSSI a partir de respectivos dispositivos de nó para a instalação central. Com a prática dessa metodologia, as condições do ambiente de RF no qual essa rede reside podem ser avaliadas.
Uma outra modalidade de exemplo presente se refere a uma metodologia mais particularmente relativa a uma metodologia para uma rede de malha de salto de freqüência de sistema de medição avançado com ferramentas de avaliação ambiental de RF embutidas para calibração das necessidades de performance de transceptor de RF dessa rede. Essa metodologia de exemplo pode compreender o estabelecimento de uma rede que inclui uma instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo relês de célula os quais provêem comunicações entre outros dos dispositivos de nó e a instalação central; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos de nó através de associações com respectivos relês de célula; a tomada de leituras seletivamente de Indicador de Intensidade de Sinal Recebido (RSSI) em respectivos dispositivos de nó; a realização de uma análise estatística em cada um desses respectivos dispositivos de nó para computação de dados de RSSI médio e dados de função de autocorrelação de RSSI com base em leituras de RSSI em cada um desses respectivos dispositivos de nó; e o relatório desses dados de RSSI médios computados e de dados de função de autocorrelação de RSSI para a instalação central para uso na análise das características de tempo de interferência de RF, com base na experiência de ambiente eletromagnético de dispositivo de nó para dispositivo de nó real da rede.
Ainda uma outra modalidade de exemplo presente ser refere a uma rede de malha de sistema de medição avançado com ferramentas de avaliação ambiental de RF embutidas. Essa rede pode compreender, preferencialmente, uma instalação central; e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia; e pelo menos alguns desses dispositivos de nó compreendem relês de célula os quais provêem comunicações entre outros desses dispositivos de nó e a instalação central, com cada dispositivo de nó configurado para comunicações bidirecionais com essa instalação central. Ainda, preferencialmente cada um desses dispositivos de nó é configurado para a monitoração seletiva de dados de Indicador de Intensidade de Sinal Recebido (RSSI) em cada respectivo dispositivo de nó e relatar esses dados de RSSI a partir dali para a instalação central, de modo que as condições do ambiente de resfriamento em que essa rede reside possam ser avaliadas.
Ainda uma outra modalidade de exemplo presente se refere a uma rede de malha de salto de freqüência de sistema de medição avançado com ferramentas de avaliação ambiental de RF embutidas para calibração das necessidades de performance de transceptor de RF dessa rede. Essa rede de exemplo pode compreender preferencialmente uma instalação central; e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo relês de célula os quais provêem comunicações entre outros desses dispositivos de nó e a instalação central, com essa rede configurada para comunicações bidirecionais entre a interface de lado de cliente e cada um dessa pluralidade de dispositivos de nó através de associações com respectivos desses relês de célula. Mais ainda, preferencialmente cada um desses dispositivos de nó é configurado para seletivamente tomar leituras de Indicador de Intensidade de Sinal Recebido (RSSI) ali, realizar uma análise estatística ali para computação dos dados de RSSI médios e de dados de função de autocorrelação de RSSI, com base em leituras de RSSI ali, e reportar esses dados de RSSI médios computados e dados de função de autocorrelação de RSSI para a instalação central para uso na análise de características de tempo de interferência de RF, com base na experiência de ambiente eletromagnético de dispositivo de nó para dispositivo de nó real da rede.
Uma modalidade de exemplo presente adicional mais particularmente se refere a um dispositivo de metrologia. Esse dispositivo de metrologia preferencialmente é para uso com uma rede de malha de salto de freqüência de sistema de medição avançado com ferramentas de avaliação ambiental de RF embutidas para calibração das necessidades de performance de transceptor de RF dessa rede, e incluindo uma instalação central, uma pluralidade de dispositivos de nó, com pelo menos alguns desses dispositivos de nó compreendendo esses dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo relês de célula operando por sua própria respectiva seqüência de canais e provendo comunicações entre outros dos dispositivos de nó e a instalação central, com cada dispositivo de nó configurado para comunicações bidirecionais com essa instalação central através de pelo menos um relê associado desses relês de célula. Um dispositivo de metrologia de exemplo como esse pode compreender uma porção de metrologia configurada para a medição do consumo de um bem de consumo de serviço de utilidade pública; uma porção de transmissor configurada para a transmissão de uma informação de consumo e de outros dados; e uma porção de receptor configurada para receber uma informação a partir de outros dispositivos de rede em uma rede associada. Preferencialmente, essas porções de dispositivo de metrologia são configuradas para a monitoração seletiva de dados de Indicador de Intensidade de Sinal Recebido (RSSI) ali, e reportar esses dados de RSSI a partir dali para a instalação central de uma rede associada, de modo que as condições do ambiente de RF no qual essa rede reside possam ser avaliadas.
Uma modalidade de exemplo presente se refere a uma metodologia para uma rede de malha de sistema de medição avançado com roteamento de enlace descendente de modo múltiplo. Essa modalidade pode compreender, preferencialmente, o estabelecimento de uma rede incluindo uma instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo mestres de célula os quais provêem comunicações entre a instalação central e outros dos dispositivos de nó associados a eles nas respectivas células formadas por cada respectivo mestre de célula; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos de nó; a partir de cada dispositivo de nó associado a um dado mestre de célula específico em uma respectiva célula formada dessa forma, a provisão de uma informação para esse dado mestre de célula específico sobre enlaces de comunicações de cada um desses dispositivos de nó nessa respectiva célula; o envio seletivo de uma mensagem de enlace descendente de monodifusão a partir de um dado respectivo mestre de célula para um dispositivo de nó específico associado a ele, usando um percurso de enlace descendente de monodifusão determinado por esse dado respectivo mestre de célula com base em sua informação recebida a partir de todos os dispositivos de nó associados a ele; e o envio seletivo de uma mensagem de enlace descendente de difusão a partir de um dado respectivo mestre de célula para todos os dispositivos de nó associados a ele.
Uma outra modalidade de exemplo de metodologia presente se refere a uma rede de malha de salto de freqüência de sistema de medição avançado com um roteamento de enlace descendente de modo múltiplo dinâmico para todos os dispositivos de nó da mesma. Essa modalidade preferencialmente pode compreender uma metodologia para o estabelecimento de uma rede incluindo uma instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, pelo menos alguns desses dispositivos de nó compreendendo mestres de célula os quais provêem comunicações entre a instalação central e outros dos dispositivos de nó associados a eles em respectivas células formadas por cada respectivo mestre de célula, e pelo menos alguns desses dispositivos de nó compreendem dispositivos de nó pais os quais provêem um enlace de comunicações entre um respectivo mestre de célula e outros dos dispositivos de nó definindo dispositivos de nó filhos de um dado respectivo dispositivo de nó pai na respectiva célula do respectivo mestre de célula; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos de nó através de associações com respectivos mestres de célula; em cada dispositivo de nó, a manutenção de uma tabela de vizinho contendo uma informação sobre cada um desses dispositivos de nó e suas respectivas relações de vizinho e enlaces de comunicações em uma respectiva célula formada por um respectivo mestre de célula; a partir de cada dispositivo de nó associado a um dado mestre de célula especifico em uma respectiva célula formada dessa forma, o encaminhamento da tabela de vizinho do mesmo para esse dado mestre de célula específico; em cada dispositivo de nó associado a um dado mestre de célula específico em uma respectiva célula formada dessa forma, a atualização de sua respectiva tabela de vizinho quando quaisquer mudanças ocorrerem em qualquer uma de suas respectivas relações de vizinho ou enlaces de comunicações, e o encaminhamento dessa tabela de vizinho atualizada do mesmo para esse mestre de célula específico; o envio seletivo de uma mensagem de enlace descendente de difusão a partir de um dado respectivo mestre de célula para todos os dispositivos de nó associados a ele em sua respectiva célula; e o envio seletivo de uma mensagem de enlace descendente de monodifusão a partir de um dado respectivo mestre de célula para um dispositivo de nó específico associado a ele na respectiva célula formada por esse dado respectivo mestre de célula, usando-se um percurso de enlace descendente de monodifusão determinado por esse dado respectivo mestre de célula, com base em tabelas de vizinho recebidas a partir de todos os dispositivos de nó associados a ele em sua respectiva célula. Com essa modalidade, essa rede adapta dinamicamente seu roteamento de enlace descendente a mudanças em enlaces de comunicações dentre os dispositivos de nó da mesma.
Ainda uma outra modalidade de exemplo presente se refere a uma rede de malha de sistema de medição avançado com roteamento de enlace descendente de modo múltiplo. Uma modalidade como essa preferencialmente compreende uma instalação central; e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo mestres de célula os quais provêem comunicações entre a referida instalação central e outros dos referidos dispositivos de nó associados a ele em respectivas células formadas por cada respectivo mestre de célula, com cada dispositivo de nó configurado para comunicações bidirecionais com a referida instalação central. Nessa modalidade,
preferencialmente, cada um dos referidos dispositivos de nó é configurado para prover uma informação para seu respectivo mestre de célula sobre enlaces de comunicações do mesmo nessa respectiva célula; e cada respectivo mestre de célula é configurado para seletivamente enviar uma mensagem de enlace descendente de monodifusão a partir dele para um dispositivo de nó especifico associado a ele, usando um percurso de enlace descendente de monodifusão determinado por ele com base em sua informação recebida a partir de todos os dispositivos de nó associados a ele, e ainda é configurado para seletivamente enviar uma mensagem de enlace descendente de difusão a partir dele para todos os dispositivos de nó associados a ele.
Em uma outra modalidade de exemplo presente, uma rede de malha de salto de freqüência de sistema de medição avançado tem um roteamento de enlace descendente de modo múltiplo dinâmico para todos os dispositivos de nó da mesma. Essa rede preferencialmente compreende uma instalação central; e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, pelo menos alguns desses dispositivos de nó compreendendo mestres de célula, os quais provêem comunicações entre a referida instalação central e outros dos referidos dispositivos de nó associados a isso nas respectivas células formadas por cada respectivo mestre de célula, e pelo menos alguns desses dispositivos de nó compreendendo dispositivos de nó pais os quais provêem um enlace de comunicações entre um respectivo mestre de célula e outros dos referidos dispositivos de nó definindo dispositivos de nó filhos de um dado respectivo dispositivo de nó pai na respectiva célula do respectivo mestre de célula, com cada um dos referidos dispositivos de nó configurado para comunicações bidirecionais entre a referida instalação central e cada um da referida pluralidade de dispositivos de nó através de associações com respectivos mestres dos referidos mestres de célula. Nessa modalidade de exemplo, preferencialmente cada um dos referidos dispositivos de nó é configurado para manutenção de uma tabela de vizinho contendo uma informação sobre suas respectivas relações de vizinho e enlaces de comunicações em uma respectiva célula formada por seu respectivo mestre de célula, para encaminhamento desta tabela de vizinho para seu respectivo mestre de célula, para atualização de sua respectiva tabela de vizinho quando quaisquer mudanças ocorrerem em qualquer uma de suas respectivas relações de vizinho ou enlaces de comunicação, e para encaminhamento dessa tabela de vizinho atualizada para seu respectivo mestre de célula; e cada respectivo mestre de célula é configurado para seletivamente enviar uma mensagem de enlace descendente de difusão para todos os dispositivos de nó em seu respectivo mestre de célula, e para o envio seletivo de uma mensagem de enlace descendente de monodifusão para um dispositivo de nó especifico associado a sua respectiva célula, usando-se um percurso de enlace descendente de monodifusão determinado por ele cora base nas tabelas de vizinho recebidas a partir de todos os dispositivos de nó em sua respectiva célula. Com um arranjo como esse, a rede adapta dinamicamente seu roteamento de enlace descendente a mudanças em enlaces de comunicações dentre os referidos dispositivos de nó da mesma.
Ainda uma outra modalidade de exemplo presente se refere mais particularmente a um dispositivo de metrologia para uso com uma rede de malha de sistema de medição avançado com roteamento de enlace descendente de modo múltiplo, e incluindo uma instalação central, uma pluralidade de dispositivos de nó, com pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo mestres de célula, que provêem comunicações entre a referida instalação central e outros dos dispositivos de nó associados a isso nas respectivas células formadas pelos respectivos mestres de célula, com cada dispositivo de nó configurado para comunicações bidirecionais com essa instalação central através de associações com respectivos mestres de célula. Um dispositivo de metrologia de exemplo como esse preferencialmente pode compreender uma porção de metrologia configurada para a medição do consumo de um bem de consumo de serviço de utilidade pública; uma porção de transmissor configurada para transmitir uma informação de consumo e outros dados; e uma porção de receptor configurada para receber uma informação a partir de outros dispositivos de rede em uma rede associada. Essas porções de dispositivo de metrologia preferencialmente são configuradas para a manutenção de uma tabela de vizinho contendo uma informação sobre suas respectivas relações de vizinho e enlaces de comunicações em uma respectiva célula formada por seu respectivo mestre de célula em uma rede associada, para encaminhamento de sua tabela de vizinho para seu respectivo mestre de célula, para atualização de sua respectiva tabela de vizinho, quando quaisquer mudanças ocorrerem em qualquer uma de suas relações de vizinho ou enlaces de comunicações, e para encaminhamento dessa tabela de vizinho atualizada para seu respectivo mestre de célula, de modo que esse mestre de célula possa seletivamente encaminhar mensagens de enlace descendente para os respectivos dispositivos de nó de sua célula para chegarem ao dispositivo de nó pretendido.
Um número de exemplo presente se refere a uma metodologia para se permitirem notificações de falta em uma rede de malha de sistema de medição avançado. Essa presente metodologia de exemplo pode compreender o estabelecimento de uma rede incluindo uma instalação central e uma pluralidade de dispositivos finais, pelo menos alguns desses dispositivos finais compreendendo dispositivos de metrologia; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos finais; fazer com que um dispositivo final experimentando condições de falta de potência transmita uma mensagem de falta de potência para dispositivos finais vizinhos; e a configuração da pluralidade de dispositivos finais de modo que dispositivos finais vizinhos não experimentando uma falta de potência respondam a uma mensagem de falta de potência para encaminhamento dessa mensagem de falta de potência para a instalação central pela rede. Com uma metodologia de exemplo como essa, vantajosamente os dados de falta de potência são reportados para a instalação central através da rede usando-se dispositivos finais não experimentando condições de falta de potência, sem se requerer um enlace de comunicações direto entre a instalação central e um dispositivo final experimentando condições de falta de potência.
O assunto de aparelho presente de exemplo pode se relacionar a uma rede de malha de sistema de medição avançado com uma funcionalidade de notificação de falta de potência. Uma presente rede como essa de exemplo pode compreender uma instalação central; e uma pluralidade de dispositivos finais, pelo menos alguns desses dispositivos finais compreendendo dispositivos de metrologia, com a referida instalação central e a referida pluralidade de dispositivos finais sendo configuradas para comunicações bidirecionais entre elas. Com um arranjo de exemplo como esse, a pluralidade de dispositivos finais é configurada de modo que um dispositivo final experimentando condições de falta de potência transmita uma mensagem de falta de potência para dispositivos finais vizinhos. Essa pluralidade de dispositivos finais preferencialmente ainda é configurada de modo que os dispositivos finais vizinhos não experimentando uma falta de potência respondam a uma mensagem de falta de potência para encaminhamento dessa mensagem de falta de potência para a referida instalação central pela referida rede. Com um arranjo como esse, os dados de falta de potência são reportados para a referida instalação central através da referida rede usando-se dispositivos finais não experimentando condições de falta de potência, sem se requerer um enlace de comunicações direto entre a referida instalação central e um dispositivo final experimentando condições de falta de potência.
Outras presentes modalidades de exemplo podem se relacionar mais diretamente ao assunto de dispositivo variado, tal como um dispositivo de metrologia com uma funcionalidade de notificação de falta de potência para uso com uma rede de malha de sistema de medição avançado tendo uma instalação central e uma pluralidade de outros dispositivos de rede, pelo menos alguns deles compreendendo outros dispositivos de metrologia. Um dispositivo de metrologia como esse preferencialmente pode compreender uma porção de metrologia configurada para medir o consumo de um bem de consumo de serviço de utilidade pública; uma porção de transmissor configurada para transmitir uma informação de consumo e outros dados; e uma porção de receptor configurada para receber uma informação a partir de outros dispositivos de rede. Preferencialmente, esse dispositivo de metrologia é configurado, quando experimentando condições de falta de potência, para fazer com que a referida porção de metrologia cesse a medição de consumo e para fazer com que a referida porção de transmissor transmita uma mensagem de falta de potência; e esse dispositivo de metrologia ainda é configurado, quando não experimentando condições de falta de potência, para fazer com que a referida porção de receptor receba uma mensagem de falta de potência a partir de um outro dispositivo de metrologia, e fazer com que a referida porção de transmissor transmita essa mensagem de falta de potência.
Um método de exemplo como esse pode compreender o estabelecimento de uma rede incluindo uma o estabelecimento de uma rede incluindo um nó de raiz de instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia; a configuração da rede para comunicações bidirecionais entre o nó de raiz de instalação central e cada um da pluralidade de dispositivos de nó; a computação de um atraso de propagação local médio para cada enlace de um salto; a computação do atraso de propagação total ao longo de cada percurso até o nó de raiz de instalação central; a seleção em cada dispositivo de nó do valor mais curto de atraso de propagação total para a definição de seu próprio valor de atraso de propagação global; e a condução de comunicações usando o percurso correspondente ao valor selecionado. Com um método de exemplo como esse, as comunicações dentre os nós na rede são otimizadas.
Ainda uma outra presente metodologia de exemplo se refere a um método para a otimização de uma rede de malha de sistema de medição avançado. Essa presente metodologia de exemplo pode compreender o estabelecimento de uma rede incluindo um nó de raiz de instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia; a configuração da rede para comunicações bidirecionais entre o nó de raiz de instalação central e cada um da pluralidade de dispositivos de nó; a computação de um atraso de propagação local médio para cada enlace de um salto; a propagação de uma informação de atraso de propagação global a partir do nó de raiz de instalação central para cada um dos dispositivos de nó em uma base passo a passo; o armazenamento da informação de atraso de propagação global em cada dispositivo de nó; e a condução de comunicações usando um percurso correspondente ao valor mais curto de atraso de propagação total, com base na informação de atraso de propagação global armazenada e no atraso de propagação local médio. Com uma metodologia como essa, cada dispositivo de nó pode selecionar um percurso de comunicações com base apenas no conhecimento de seu próprio atraso de propagação local médio e na informação de atraso de propagação global a partir dos dispositivos de nó vizinhos imediatos.
Ainda outras metodologias de exemplo presentes são providas pela incorporação alternativamente de vários recursos presentes. Um exemplo é a inclusão adicional de cada nó tornado disponível seu valor de atraso de propagação global pela atualização de seu cabeçalho de mensagem. Ainda em outras alternativas, as presentes metodologias de exemplo podem incluir o atraso de propagação local médio ser derivado pela manutenção de um registro de todas as tentativas de comunicação com cada um da pluralidade de dispositivos de nó na direção do nó de raiz de instalação central; e a computação de uma taxa de sucesso de comunicação estatística para cada um da pluralidade de dispositivos de nó.
Em certas presentes alternativas, o atraso de propagação local médio para cada enlace de um salto é computado usando-se a relação: <formula>formula see original document page 53</formula>
onde D é o atraso de propagação local médio, Ta é o tempo necessário para um pacote viajar de um transmissor para um receptor, P é a taxa de sucesso de pacote, e Tr é o tempo de espera entre transmissões. Em certas presentes metodologias alternativas de exemplo, a taxa de sucesso de pacote pode ser atualizada após cada tentativa de transmissão de pacote com uma média deslizante usando a relação:
<formula>formula see original document page 53</formula>
onde P(n) é a taxa de sucesso de pacote para um dado nó n, Nav é o número de transmissões usadas para a computação da média, e PS(n) é uma indicação de sucesso ou falha em uma tentativa n, onde PS (n) = 0 se uma transmissão η tiver falhado e PS(η) = 1 se uma transmissão η tiver sido bem sucedida. Nesses métodos alternativos, o atraso de propagação de qualquer enlace pode ser atualizado usando-se a relação:
<formula>formula see original document page 53</formula>
onde Dr (n) é o atraso de propagação de um enlace para transmissão η e PS (n) é uma indicação de sucesso ou falha em uma tentativa n, onde PS (n) = 0 se uma transmissão η tiver falhado, e PS(η) = 1 se uma transmissão η tiver sido bem sucedida.
É para ser entendido que o presente assunto igualmente pertence ao assunto de aparelho correspondente. Uma modalidade de exemplo presente se refere a uma rede de malha de sistema de medição avançado, que compreende um nó de raiz de instalação central; e uma pluralidade de dispositivos de nó. Preferencialmente, nessa modalidade de exemplo, cada dispositivo de nó é configurado para comunicações bidirecionais com o referido nó de raiz de instalação central, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia. Nessa modalidade de exemplo, cada dispositivo de nó é adicionalmente configurado para a computação de um atraso de propagação local médio para cada enlace de um salto para si mesmo na rede de malha e para selecionar o percurso de transmissão mais curto para o referido nó de raiz de instalação central, com base apenas em seu próprio atraso de propagação médio computado e em uma informação de atraso de propagação global armazenada em seus vizinhos imediatos. Com um arranjo como esse, as comunicações entre o nó de raiz de instalação central e a referida pluralidade de dispositivos de nó pode ser otimizada.
Uma presente modalidade de exemplo se refere a um método para habilitar um dispositivo final de rede recém instalado para o estabelecimento de um enlace com uma rede de salto de freqüência de sistema de medição avançado existente. Um método de exemplo como esse pode compreender o estabelecimento de uma rede incluindo uma instalação central e uma pluralidade de dispositivos finais, pelo menos alguns desses dispositivos finais compreendendo dispositivos de metrologia; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos finais; fazer com que um dispositivo final recém instalado transmita um sinal de orientação de descoberta, o sinal de orientação de descoberta incluindo uma informação quanto a um canal de escuta específico no qual o dispositivo final recém instalado escutará durante uma janela de escuta; a configuração da pluralidade selecionada de dispositivos finais para a transmissão de uma resposta a um sinal de orientação de descoberta recebido; a colocação do dispositivo final recém instalado em um modo de escuta durante uma janela de escuta no canal de escuta especificado no sinal de orientação de descoberta transmitido; a configuração do dispositivo final recém instalado para a coleta e o armazenamento de uma informação transmitida a partir de um ou mais da pluralidade de dispositivos finais em resposta ao sinal de orientação de descoberta; e a configuração do dispositivo final recém instalado para sincronização com uma rede preferida, com base em qualquer informação coletada de acordo com critérios predeterminados.
Outras presentes modalidades de exemplo se referem a um sistema de medição avançado. Um sistema presente de exemplo como esse pode se referir a uma rede de salto de freqüência de sistema de medição avançado, que compreende uma instalação central e uma pluralidade de dispositivos finais. Preferencialmente, pelo menos alguns desses dispositivos finais compreendem dispositivos de metrologia, com a instalação central e essa pluralidade de dispositivos finais sendo configuradas para comunicações bidirecionais entre si. Ainda, pelo menos um dispositivo é incluído, configurado para se tentar estabelecer um enlace com pelo menos um dessa pluralidade de dispositivos finais de acordo com critérios predeterminados. Com essa modalidade de exemplo, preferencialmente pelo menos um desses dispositivos é configurado para tentar o estabelecimento de um enlace pela transmissão de uma pluralidade de sinais de orientação de descoberta em canais de salto sucessivos, cada sinal de orientação incluindo uma informação quanto a um canal específico no qual pelo menos um referido dispositivo escutará durante uma janela de escuta, e quanto ao número de sinais de orientação remanescentes a serem transmitidos.
Uma outra presente modalidade de exemplo se refere mais particularmente a um dispositivo de metrologia para uso com uma rede de salto de freqüência de sistema de medição avançado. Um presente dispositivo de exemplo como esse pode compreender uma porção de metrologia configurada para medir o consumo de um bem de consumo de serviço de utilidade pública; uma porção de transmissor configurada para transmitir uma informação de consumo; e uma porção de receptor configurada para receber uma informação a partir de outros dispositivos de rede. Com um presente dispositivo de exemplo como esse, o dispositivo de metrologia é configurado para fazer com que a porção de transmissor transmita sinais de orientação de descoberta por vários canais de salto em sucessão, começando com um canal de salto selecionado randomicamente, cada sinal de orientação de descoberta incluindo o número de sinais de orientação de descoberta remanescentes a serem enviados e o canal no qual a porção de receptor escutará uma resposta.
Uma presente modalidade de exemplo se refere a um método para gerenciamento de tamanho de célula em uma rede de malha de sistema de medição avançado. Essa metodologia de exemplo preferencialmente pode compreender o estabelecimento de uma rede de malha que inclui pelo menos uma célula incorporando pelo menos um nó mestre e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó sendo organizados em pelo menos uma célula; a configuração da rede para comunicações bidirecionais dentre pelo menos um nó mestre e cada um da pluralidade de dispositivos de nó usando um hiperquadro de repetição subdividido em um protocolo de pacote de intervalo de tempo de repetição; a sincronização de uma pluralidade dos dispositivos de nó para pelo menos um nó mestre; o estabelecimento de um indicador de tamanho de célula com base no número de dispositivos de nó sincronizados para o nó mestre; o estabelecimento de um atraso de propagação médio global com base no atraso de propagação médio presentemente entre cada dispositivo de nó e o nó mestre; a transmissão do indicador de tamanho de célula e da informação de atraso de propagação médio global como uma porção de qualquer mensagem transmitida a partir do nó mestre; e em caàa respectivo dispositivo de nó, a classificação e a seleção de vizinhos do mesmo para seleção do melhor acesso para sincronização e para se fazer uma escolha entre células disponíveis diferentes.
Uma outra presente modalidade de exemplo se refere a uma rede de malha de sistema de medição avançado. Essa modalidade de exemplo preferencialmente pode compreender uma rede de malha que inclui pelo menos uma célula que incorpora pelo menos um nó mestre e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó sendo organizados em pelo menos uma célula, com essa rede de malha configurada para comunicações bidirecionais dentre pelo menos um nó mestre e cada um da pluralidade de dispositivos de nó, usando um hiperquadro de repetição subdividido em um protocolo de pacote de intervalo de tempo de repetição, e com uma pluralidade de dispositivos de nó sincronizados com o nó mestre; e um transmissor, associado ao nó mestre, e configurado para a transmissão de um indicador de tamanho de célula com base no número de dispositivos de nó sincronizados com o nó mestre, e para a transmissão de um atraso de propagação médio global com base no atraso de propagação médio respectivamente entre cada dispositivo de nó e o nó mestre, com essas transmissões compreendendo uma porção de qualquer mensagem transmitida a partir do nó mestre. Ainda, preferencialmente, esses dispositivos de nó são configurados para o recebimento de mensagens a partir do referido transmissor, e com base nisso, a classificação e a seleção de vizinhos dos mesmos de modo a se selecionar o melhor acesso para sincronização e de modo a se fazer uma escolha entre células disponíveis diferentes.
Recursos presentes adicionais podem ser praticados, de forma alternativa e/ou adicional com as modalidades de exemplo precedentes, por meio do que as presentes modalidades adicionais são providas.
Objetivos e vantagens adicionais do presente assunto são estabelecidos em ou serão evidentes para aqueles de conhecimento comum na técnica a partir da descrição detalhada aqui. Também deve ser adicionalmente apreciado que modificações e variações nos recursos, elementos e etapas especificamente ilustrados, referidos e discutidos daqui podem ser praticadas em várias modalidades e usos do presente assunto, sem que se desvie do espirito e do escopo do assunto. As variações podem incluir, mas não estão limitadas a uma substituição de meios, recursos ou etapas equivalentes por aquelas ilustradas, referenciadas ou discutidas, e a reversão funcional, operacional ou de posição de várias partes, recursos, etapas ou similares.
Mais ainda, é para ser entendido que modalidades diferentes, bem como modalidades presentemente preferidas diferentes do presente assunto podem incluir várias combinações ou configurações de recursos, etapas ou elementos presentemente mostrados ou seus equivalentes, incluindo combinações de recursos, partes ou etapas ou configurações dos mesmos não expressamente mostradas nas figuras ou declaradas na descrição detalhada dessas figuras. Modalidades adicionais do presente assunto não expressadas necessariamente na seção de sumário podem incluir e incorporar várias combinações de aspectos de recursos, componentes ou etapas referenciados nos objetivos resumidos acima e/ou outros recursos, componentes ou etapas, conforme discutido de outra forma neste pedido. Aqueles de conhecimento comum na técnica mais bem apreciarão os recursos e os aspectos dessas modalidades e de outras, mediante uma revisão do restante do relatório descritivo.
BREVE DESCRIÇÃO DOS DESENHOS
Uma exposição plena e capacitante do presente assunto, incluindo o melhor modo do mesmo, dirigido a alguém de conhecimento comum na técnica, é estabelecida no relatório descritivo, o que faz referência às figuras em apenso, nas quais:
a FIGURA 1 descreve o assunto do MODELO DE OSI;
a FIGURA 2A descreve o assunto de ARQUITETURA DE REDE;
a FIGURA 2B descreve o assunto de MODELO DE CAMADA;
a FIGURA 3A é uma ilustração de visão geral de diagrama de blocos de um Sistema de Medição Avançado (AMS) e uma representação de uma metodologia correspondente do mesmo, de acordo com o presente assunto;
a FIGURA 3B ilustra um diagrama de blocos de um medidor de exemplo que incorpora recursos de interface de acordo com o presente assunto;
a FIGURA 3C ilustra um emprego de Sistema de Medição Avançado que incorpora vários dos aspectos de aparelho e de metodologia do presente assunto;
a FIGURA 3D ilustra esquematicamente uma metodologia de exemplo e o aparelho correspondente para a transmissão de um firmware para dispositivos finais de acordo com o presente assunto;
a FIGURA 3E ilustra esquematicamente uma metodologia de exemplo e um aparelho correspondente para a transmissão de imagens de firmware diferentes para dispositivos finais selecionados;
a FIGURA 3F ilustra um diagrama de blocos dos componentes de um Agente de Coleta de acordo com uma modalidade de exemplo do presente assunto;
a FIGURA 4 descreve o assunto de QUADRO DE ASSUNTO PRESENTE INTEIRO PARA UMA MENSAGEM DE ENLACE ASCENDENTE;
a FIGURA 5 descreve o assunto de BLOCOS DE DADOS PARA CODIFICAÇÃO / DECODIFICAÇÃO DE FEC;
a FIGURA 6 descreve o assunto de TABELA DE ENTRELAÇAMENTO PARA CODIFICAÇÃO / DECODIFICAÇÃO DE FEC;
a FIGURA 7 descreve o assunto de MDPU APÓS ENTRELAÇAMENTO E CODIFICAÇÃO DE REED-SOLOMON
a FIGURA 8 descreve o assunto de CODIFICADOR DE REED- SOLOMON;
a FIGURA 9 descreve o assunto de QUADRO DE PHY;
a FIGURA 10 descreve o assunto de SERVIÇOS DE CAMADA FÍSICA;
a FIGURA 11 descreve o assunto de DIVISÃO DE TEMPO E DE FREQÜÊNCIA;
a FIGURA 12 descreve o assunto de HIPERQUADRO E SEQÜÊNCIA DE CANAL (15 CANAIS, 10 SEQÜÊNCIAS BÁSICAS);
a FIGURA 13 descreve o assunto de ESTRUTURA DE HIPERQUADRO;
a FIGURA 14 descreve o assunto de ELEMENTOS PRIMITIVOS PARA SEQÜÊNCIAS DE SALTO BÁSICAS DE PHY-FHSS-NA-915;
a FIGURA 15 descreve o assunto de MARGENS DE TS E SUBINTERVALOS DE TEMPO;
a FIGURA 16 descreve o assunto de ESTRUTURA DE MANUTENÇÃO DE TEMPO DE PROTOCOLO;
a FIGURA 17 descreve o assunto de FORMATO DE ESTAMPA DE TEMPO DE ITP PADRÃO;
a FIGURA 18 descreve o assunto de SINCRONIZAÇÃO E NÍVEIS;
a FIGURA 19 descreve o assunto de SINCRONIZAÇÃO HIERÁRQUICA;
a FIGURA 20 descreve o assunto de RESSINCRONIZAÇÃO ENTRE PONTOS FINAIS;
a FIGURA 21A descreve pais de SYNC potenciais e pais saudáveis para um assunto de nó sincronizado;
a FIGURA 21B descreve o assunto de Grau de Conectividade;
a FIGURA 22 descreve o assunto de EXEMPLO DE DESCOBERTA DE FASE COM NÚMERO DE SEQÜÊNCIA DE SALTO DE FREQÜÊNCIA BÁSICO 0 DE 915;
a FIGURA 23 descreve uma Tabela relativa a exemplos do assunto de vizinhos preferidos;
a FIGURA 24 descreve o assunto de EXEMPLO DE CONFIGURAÇÃO;
a FIGURA 25 descreve o assunto de EXEMPLO DE PROCESSO DE SINCRONIZAÇÃO;
as FIGURAS 26A e 26B descrevem respectivamente um exemplo de uma Configuração Inicial e um exemplo de um novo ponto final, ilustrativos de circunstâncias de um ponto final descobrindo um melhor ponto final para fins de comunicação, pelo presente assunto;
a FIGURA 27 descreve um assunto de RESSINCRONIZAÇÕES E CORREÇÕES DE DERIVA DE CRISTAL NO TEMPO;
a FIGURA 2 8 descreve o assunto de ALGORITMO DE COMPENSAÇÃO DE DERIVA DE RELÓGIO LOCAL;
a FIGURA 2 9 descreve o assunto de FILTRO DE PASSA BAIXA PARA CORREÇÃO DE DERIVA DE RELÓGIO;
a FIGURA 30A descreve o assunto de Gerenciamento de Tabela de Vizinho;
a FIGURA 30B descreve o assunto de IMPLEMENTAÇÃO DE CRC32 TÍPICA;
a FIGURA 31 descreve o assunto de MONITORAÇÃO DE CARGA DE TRÁFEGO: O NÓ B ESTÁ OUVINDO A(S) MENSAGEM (NS) DE (N)ACK A PARTIR DE SEUS PAIS A E C;
a FIGURA 32 descreve o assunto de protocolo presente de assunto de LISTA DE PRIORIDADE DE MENSAGENS;
a FIGURA 33 descreve o assunto de PDF DE RSSI;
a FIGURA 34 descreve o assunto de RELATÓRIO DE PDF DE RSSI;
a FIGURA 35 descreve o assunto de QUADRO DE MAC;
a FIGURA 36 descreve o assunto de TIPO DE QUADRO DE MAC;
a FIGURA 37 descreve o assunto de SINAL DE ORIENTAÇÃO;
a FIGURA 38 descreve o assunto de REQUISIÇÃO DE SYNC;
a FIGURA 39 descreve o assunto de ACK - NACK - SYNC NACK;
a FIGURA 40 descreve o assunto de SYNC ACK;
a FIGURA 41 descreve o assunto de SINAL DE ORIENTAÇÃO DE REQUISIÇÃO;
a FIGURA 42 descreve o assunto de DADOS DE MONODIFUSÃO;
a FIGURA 43 descreve o assunto de DADOS DE MULTIDIFUSÃO;
a FIGURA 44 descreve o assunto de ITP;
a FIGURA 45 descreve o assunto de SINAL DE ORIENTAÇÃO DE DESCOBERTA; a FIGURA 46 descreve o assunto de FALTA;
a FIGURA 47 descreve o assunto de SERVIÇOS DE CAMADA DE MAC;
a FIGURA 48 descreve o assunto de DIAGRAMA DE ESTADOS EM GERAL;
a FIGURA 49 descreve o assunto de VALORES PADRÕES DE PARÂMETRO DE LLC;
a FIGURA 50 descreve o assunto de RETORNO APÓS COLISÃO EXPONENCIAL BINÁRIO TRUNCADO ATRASADO PARA NOVAS TENTATIVAS DE TRANSMISSÃO SE PACOTES NÃO FOREM RECONHECIDOS;
a FIGURA 51 descreve o assunto de RETORNO APÓS COLISÃO EXPONENCIAL BINÁRIO TRUNCADO PARA NOVAS TENTATIVAS DE TRANSMISSÃO SE PACOTES FOREM RECONHECIDOS NEGATIVAMENTE;
a FIGURA 52 descreve o assunto de TABELA DE DUPLICAÇÃO DE LLC;
a FIGURA 53 descreve o assunto de QUADRO DE LLC;
a FIGURA 54 descreve o assunto de SERVIÇOS DE CAMADA DE LLC;
a FIGURA 55 descreve o assunto de VALORES PADRÕES DE PARÂMETRO DE CAMADA DE NET;
a FIGURA 56 descreve o assunto de TABELA DE DUPLICAÇÃO DE NET;
a FIGURA 5 7A descreve o assunto de Topologia para um exemplo de roteamento de enlace descendente;
a FIGURA 57B descreve o assunto de Tabela de Roteamento de CR para um exemplo de roteamento de enlace descendente;
a FIGURA 57C descreve o assunto de Indicador de tamanho de célula (% de NET_Max_Nb_of_EPs);
a FIGURA 57D descreve o assunto de ações de mestre de célula quando a camada de eletrodo está cheia ou o nó não em tabela de roteamento;
a FIGURA 58 descreve o assunto de QUADRO DE NET;
a FIGURA 5 9 descreve o assunto de TIPO DE QUADRO DE NET ;
a FIGURA 6 0 descreve o assunto de QUADRO DE ENLACE ASCENDENTE;
a FIGURA 61 descreve o assunto de QUADRO DE ENLACE DESCENDENTE;
a FIGURA 62 descreve o assunto de LISTA DE VIZINHO;
a FIGURA 63 descreve o assunto de ENLACE ASCENDENTE COM QUADRO DE LISTA DE VIZINHO;
a FIGURA 64 descreve o assunto de DIFUSÃO;
a FIGURA 65 descreve o assunto de NOTIFICAÇÃO DE CÉLULA FORA;
a FIGURA 6 6 descreve o assunto de ENLACE ROMPIDO;
a FIGURA 6 7 descreve o assunto de FALTA;
a FIGURA 6 8 descreve o assunto de NOTIFICAÇÃO DE SAÍDA DE CÉLULA;
a FIGURA 6 9 descreve o assunto de SERVIÇOS DE CAMADA DE REDE;
a FIGURA 7 0 descreve o assunto de MODELO DE LAÇO DE RETORNO DE COMPENSAÇÃO DE DERIVA DE CRISTAL;
a FIGURA 71 descreve uma versão simplificada do
assunto de MODELO DE LAÇO DE RETORNO DE COMPENSAÇÃO DE DERIVA DE CRISTAL, conforme representado na FIGURA 70;
a FIGURA 72 descreve o assunto de RESPOSTA DE DEGRAU DE CORREÇÃO DE DERIVA DE CRISTAL;
as FIGURAS 73A, 73B e 73C, respectivamente, ilustram aspectos diagramáticos do presente assunto em relação ã otimização de uma rede de malha;
a FIGURA 74 descreve o assunto de CAUSAS E SOLUÇÕES DE FALHA DE TRANSMISSÃO;
a FIGURA 7 5 descreve o assunto de MODELO PARA A CARGA DE TRÁFEGO NO RELÊ DE CÉLULA;
a FIGURA 7 6 descreve o assunto de RITMO DE TRANSFERÊNCIA DE DADOS, T(Β,A,A) E PSR (COM RECONHECIMENTO) VERSUS DENSIDADE DE ENTRADA DE TRÁFEGO, R(BfAfA) PARA PSRE = 0,8;
a FIGURA 77 descreve o assunto de RITMO DE TRANSFERÊNCIA DE DADOS, T(Β,A,A) VERSUS PSRE;
a FIGURA 7 8 descreve o assunto de TEMPO DE ESPERA E JANELA DE RANDOMIZAÇÃO PARA A (RE)TRANSMISSÃO DE UM PACOTE;
a FIGURA 7 9 descreve o assunto de COLISÃO, PACOTE 1 É PERDIDO; e
a FIGURA 8 0 descreve o assunto de COLISÃO, AMBOS OS PACOTES PODERIAM SER PERDIDOS.
0 uso repetido de caracteres de referência por todo o presente relatório descritivo e nos desenhos em apenso é pretendido para a representação dos mesmos recursos, elementos ou etapas, ou análogos, do presente assunto.
DESCRIÇÃO DETALHADA DAS MODALIDADES PREFERIDAS Uma discussão variada aqui faz uso de e/ou se baseia em abreviações e acrônimos tendo os significados pretendidos, conforme estabelecido na Tabela de Definições em apenso, a qual faz parte da presente exposição.
Um modelo de referência para interconexão de sistemas abertos (referida como OSI - Interconexão de Sistemas Abertos) foi descrita pela ISO (a Organização Internacional para Padronização). Esse modelo, representado pela presente Figura 1, é uma decomposição funcional de um sistema de comunicação. Em outras palavras, as camadas diferentes realizam funções diferentes. Uma camada N oferece serviços para a camada acima N+1, pela melhoria dos serviços oferecidos a esta camada N pela camada subjacente N-1. Essa arquitetura permite modificações adicionais em uma camada sem a mudança das outras. Mais ainda, permite uma compatibilidade entre diferentes períodos de tempo com base no mesmo princípio.
As combinações selecionadas de aspectos da tecnologia mostrada correspondem a uma pluralidade de modalidades diferentes do presente assunto. Deve ser notado que cada uma das modalidades de exemplo apresentadas e discutidas aqui não deve insinuar limitações do presente assunto. Recursos ou etapas ilustradas ou descritas como parte de uma modalidade podem ser usados em combinação com aspectos de uma outra modalidade para a produção ainda de outras modalidades. Adicionalmente, certos recursos podem ser intercambiados com dispositivos ou recursos similares não expressamente mencionados, os quais realizam a mesma função ou uma similar.
O presente assunto de rede e arquitetura de protocolo pode ser descrito com base em uma árvore de quatro tipos de elementos, espalhados em células, representados pela Figura 2A. No topo dessa arquitetura está um agente de coleta, o qual atua como um banco de dados central. Ele conhece todas as células e seus conteúdos, isto é, a célula em que cada medidor está e seu endereço. Ele também coleta dados mensalmente para todo ponto final e permite acesso a qualquer medidor na rede. O usuário pode requisitar ou enviar dados para um único medidor ou uma informação de difusão. O agente de coleta pode se comunicar com o roteador da célula selecionada por um protocolo de TCP/IP dentro da rede Internet.
Nessa hierarquia de árvore, imediatamente abaixo do agente de coleta ficam os roteadores das células, referidos como relês de célula. Há um relê de célula para cada célula e é o gateway entre medidores individuais na célula e o agente de coleta. O relê de célula contém uma tabela de roteamento de todos os medidores em sua célula. Ele também pode encaminhar dados nas duas direções, isto é, entre o agente de coleta e os pontos finais. Ele também assume o papel de sincronização da célula.
No fundo dessa árvore estão localizados os assim denominados pontos finais (EPs). Eles podem transmitir e receber uma informação de medição. Além disso, cada um deles pode atuar como um relê para pontos finais distantes sem um hardware adicional.
O último módulo indicado desses quatro tipos de elementos é a unidade de Walk-by (para ser percorrida a pé para se fazer a leitura do medidor), um portátil de ZigBee que pode se comunicar com órfãos ou configurar os parâmetros de protocolo em questão. Este módulo em si não contém o protocolo em questão. Ele usa a parte de ZigBee do registrador para comunicação com ele.
Portanto, a rede em questão usa 3 meios, os quais são o enlace de RF em questão, um enlace de RF de Zigbee, e um enlace de TCP/IP, tudo conforme representado pela presente Figura 2A.
A presente Figura 2B representa em parte o protocolo em questão, o qual em parte é baseado nas 3 primeiras camadas do modelo de camadas em questão, respectivamente rotuladas como: Física, Enlace de Dados e Camada de Rede. Essa camada de enlace de dados ainda é dividida em 2 subcamadas, MAC (controle de acesso a meio) e LLC (controle de enlace lógico). Conforme representado, cada camada pode se comunicar por meio do SAP (Ponto de acesso de serviço) com camadas imediatamente abaixo e imediatamente acima. A Figura 2B representa o modelo de camada de um EP (ponto final) que incorpora uma opção de módulo de relê de célula. No topo da pilha, a camada de API está em comunicação com o medidor em si para troca de dados de medição ou com o aplicativo de relê de célula. A pilha à esquerda representa o mestre de célula, enquanto aquela à direita é a seção de WAN de relê de célula (ou placa de relê de célula).
A discussão a seguir descreve cada camada da presente Figura 2B, incluindo suas respectivas funcionalidades e os serviços.
A interface de camada de aplicativo (API) não faz em si parte do protocolo em questão, mas de um ponto de vista de rede é a camada imediatamente acima. Uma meta principal do presente assunto é transportar dados a partir da camada de API. Em uma modalidade de exemplo, na rede de AMI a camada de API poderia seguir o protocolo C12.22, conforme discutido por toda a presente exposição. Contudo, é para ser entendido que o presente assunto também poderia funcionar com uma outra camada de API.
A camada de rede é a camada mais alta do presente assunto de protocolo. Ela está encarregada do roteamento de pacotes para seu destino final. Para ser capaz de fazer isso, ela gerencia uma tabela de seus vizinhos a um salto obtida através da camada de MAC. Para uma mensagem de enlace ascendente (em direção ao relê de célula (CR)), esta tabela permite que a camada de rede envie a mensagem para o melhor vizinho a um salto de nível mais baixo. A camada de NET do próximo ponto final repete esta operação, até atingir o relê de célula (o nível mais baixo na célula).
A camada de NET ou de relê de célula (ou mestre de célula) preferencialmente é uma exceção, uma vez que ela é aquela que pode enviar uma mensagem para qualquer ponto final (EP) na célula; é possível porque a CR NET tem todas as tabelas de vizinho (ou pais) da célula e, assim, é capaz de enviar uma mensagem com todos os endereços (o percurso inteiro) no cabeçalho. A camada CR (ou CM) NET também pode enviar uma mensagem de difusão para todos os EPs na célula. Para isto, cada camada de NET envia esta mensagem para todos os seus filhos.
A camada de controle de enlace lógico (LLC) está principalmente encarregada da repetição de mensagens que não foram ouvidas (incluindo no caso de difusão) e de fragmentação de mensagens que são longas demais. Ela também filtra mensagens duplicadas em ambas as direções, para não sobrecarregar a camada de NET ou o enlace de RF. Finalmente, freqüentemente é usada apenas como um enlace entre as camadas de NET e MAC.
A camada de controle de acesso a meio (MAC) lida com o maior número de tarefas ou funções. Em primeiro lugar, a camada de MAC é o gerenciador de sincronização. Quando a potência é ligada, ela tenta encontrar uma célula e, uma vez conectada a ela, ajusta seu nível para ficar em contato com o melhor pai possível.
É para ser entendido por aqueles de conhecimento comum na técnica que vários termos podem ser usados para a descrição de certas relações funcionais. Por exemplo, os termos pai ou pais podem ser usados de forma intercambiável em relação aos termos filho ou crianças. A escolha desses termos aqui não tem por significado portar quaisquer limitações em particular ou um significado além do contexto no qual eles são apresentados, conforme será entendido por aqueles de conhecimento comum na técnica.
Dentre as camadas do protocolo em questão, a camada de MAC é a única a ter uma noção de tempo. O tempo de protocolo em questão é dividido em intervalos de tempo (TS) e a camada de MAC os alinha com aqueles de seus pais, os quais fazem o mesmo até uma operação do relê de célula (o que é a referência de tempo na rede). Essa sincronização é feita através de uma informação de tempo incluída pelas camadas de MAC no cabeçalho de todos os pacotes. Se não houver um tráfego, a camada de MAC enviará sinais de orientação de modo que seus filhos possam ficar sincronizados com ela.
Uma outra tarefa da camada de MAC é reconhecer as mensagens recebidas. Um reconhecimento positivo ou negativo é possível (ACK ou NACK) . Estes são reconhecimento de um salto. Contudo, se a camada de API precisar de um reconhecimento de ponta a ponta, ela precisará inserir a requisição na mensagem que enviar. A camada de MAC também insere vários parâmetros pessoais no cabeçalho de todas as mensagens que envia. Quando recebendo pacotes de seus vizinhos, ela extrai estes parâmetros e gerencia uma tabela de sua vizinhança. Parte desta tabela é comunicada para a camada de NET.
Finalmente, a camada de MAC computa uma CRC (verificação de redundância cíclica) no pacote e a adiciona no fim, antes de proporcioná-la para a camada PHY para transmissão ou a usa quando da recepção de uma mensagem para detecção de erro.
A camada física (PHY) está encarregada da transmissão de dados no enlace de RF. Por padrão ela está sempre no modo de recepção e nunca decide por si se é para transmitir. Todas as suas instruções, incluindo pacotes a enviar, vêm da camada de MAC. Antes da transmissão de um pacote, ela computa e adiciona um FEC e, então, adiciona um preâmbulo e um cabeçalho a este pacote protegido. Quando recebe um pacote, ela remove estas duas adições, antes de enviar os dados para a camada de MAC. A camada física também provê a potência de pacote recebido (RSSI) e o tempo de recepção para a camada de MAC. Como um último serviço, ela também pode medir e proporcionar o valor de RSSI no canal de escuta atual.
As Figuras 3A a 3C presentes são concernidas, mais particularmente, a um aparelho de exemplo e a uma metodologia para a provisão de uma interface entre um medidor e um sistema de medição avançado e um aplicativo rodando em um sistema como esse, desse modo se permitindo uma compatibilidade de plug-n-play (isto é, uma intercambialidade) de dispositivos de metrologia na estrutura operacional aberta em questão, tal como para medidores C12.22 de padrão ANSI, discutidos em outro lugar aqui. Também, as Figuras 3D a 3F presentes se referem a aparelhos e metodologias de exemplo para a transferência (via download) de um firmware através de uma rede, conforme discutido aqui para dispositivos finais incluindo medidores de serviço de utilidade pública e relês, tal como para a atualização de um firmware em medidores de receita previamente instalados em comunicação e/ou relações de célula / nó por protocolo, conforme descrito em outro lugar aqui. Uma metodologia de propagação viral é mostrada como uma alternativa pelo menos para porções da metodologia de difusão. Vários desses recursos podem envolver a transferência (via download) de um firmware em uma rede de malha de RF que é disposta em camadas hierárquicas ou um arranjo configurado em "árvore", conforme discutido de outra forma aqui.
A Figura 3A é uma ilustração de visão geral de diagrama de blocos de um sistema de medição avançado (AMS) de acordo com o presente assunto. O sistema de medição avançado (AMS) 100 de acordo com o presente assunto é projetado para ser um sistema compreensivo para a provisão de uma informação de medição avançada e aplicativos para serviços de utilidade pública. O AMS 100 em uma parte pertinente é projetado e construído em torno de protocolos padrões de indústria e transportes e, portanto, é pretendido para funcionar com componentes em conformidade com normas de terceiros.
Os principais componentes do AMS 100 incluem os respectivos medidores de exemplo 142, 144, 146, 148, 152, 154, 156 e 158; uma ou mais respectivas redes baseadas em rádio incluindo uma rede de área de vizinhança de RF (RF NAN) 162 e seu relê de rádio associado 172, e uma rede de área de vizinhança de comunicações de linha de energia (PLC NAN) 164 e seu relê de PLC associado 174; um backhaul público baseado em IP (protocolo de internet) 18 0; e um agente de coleta 190. Outros componentes no AMS 100 de exemplo incluem uma LAN (rede de área local) de serviço de utilidade pública 192 e um firewall 194 através do qual sinais de comunicações para e do agente de coleta 190 podem ser transportados a partir de e para seus respectivos medidores de exemplo 142, 144, 146, 148, 152, 154, 156 e 158 ou outros dispositivos incluindo, mas não limitando, o relê de rádio 172 e o relê de PLC 174.
O AMS 100 é configurado para ser transparente em um contexto de transporte, de modo que os respectivos medidores de exemplo 142, 144, 146, 148, 152, 154, 156 e 158 possam ser interrogados usando-se o agente de coleta 190, independentemente de que infra-estrutura de rede existir entre eles ou dentre esses componentes. Mais ainda, devido a essa transparência, os medidores também podem responder ao agente de coleta 190 da mesma maneira.
Conforme representado pela ilustração na Figura 3A, o agente de coleta 190 é capaz de integrar medidores conectados de rádio, PLC e IP. Para facilitação dessa transparência, o AMS 100 opera e/ou tem uma interface com o protocolo de comunicação de medidor C12.22 de padrão ANSI para redes. 0 C12.22 é um protocolo transparente de rede, o qual permite comunicações através de substratos de rede dispares e assimétricos. 0 C12.22 detalha todos os aspectos de comunicações, permitindo que medidores em conformidade com C12.22 produzidos por terceiros sejam integrados em uma única solução de interface de medição avançada (AMI) única. O AMS 100 é configurado para prover leituras de medidor, bem como um controle de carga / uma resposta de demanda, envio de mensagem doméstico e capacidades de falha e restauração. Todos os dados fluindo através do sistema são enviados na forma de tabelas C12.19. O sistema prove um envio de mensagem de duas vias pleno para todo dispositivo; contudo, muitas de suas funções podem ser providas através de envio de mensagem de difusão ou de multidifusão e comunicações sem sessão.
Com referência presente à Figura 3B, é ilustrado um diagrama de blocos de um medidor 2 00 de exemplo que incorpora os recursos de interface de acordo com o presente assunto. 0 medidor 2 00 preferencialmente incorpora vários componentes, incluindo a metrologia 210, uma placa de registrador 220 e um ou mais dispositivos de comunicações. Na configuração de exemplo presentemente ilustrada, o medidor 200 pode incluir tal como uma interface de RF LAN 230 e uma antena associada 232, e uma interface de ZigBee 240 e sua antena associada 242. Além disso, um slot opcional 250 pode ser provido para a acomodação de uma rede de terceiros ou de um módulo de comunicações 252.
A metrologia 210 pode corresponder a um dispositivo de estado sólido configurado para prover (internamente em relação ao medidor) uma placa de registrador de comunicações de expressão súbita (blurt) C12.18 220. As comunicações com o medidor 200 são conduzidas através da especificação de protocolo estendido C12.22 para mensagens de medição eletrônica (EPSEM). A placa de registrador de medidor 220 é configurada para suportar plenamente as tabelas C12.19 e as extensões de C12.22. Embora todos os dados de medidor sejam acessíveis através das tabelas padronizadas de C12.19, de modo a se facilitarem comunicações de largura de banda muito baixa, as tabelas de fabricante ou os procedimentos armazenados são incluídos, os quais provêem acesso a fatias delimitadas no tempo de dados, tal como o valor de último dia do calendário de dados de intervalo ou outros "agrupamentos" personalizados de dados.
O medidor 200 pode ser configurado variadamente para a provisão de capacidades de comunicações diferentes. Nas configurações de exemplo, um ou mais dentre módulos de comunicações de GPRS, Ethernet e RF LAN podem ser providos. O GPRS permitirá que os medidores sejam endereçáveis por IP por um backhaul público e proverá mais largura de banda do que o medidor provavelmente jamais requererá, mas pode incorrer em custos de assinatura progressivos. Uma conectividade de Ethernet pode ser usada para a construção de uma ligação com tecnologias de terceiros, incluindo WiFi, WiMax, gateways domésticos e BPL (banda larga por linhas de energia), sem integração de qualquer uma destas tecnologias diretamente no dispositivo de medição, mas com a transigência de requerer uma fiação externa e uma solução em duas partes. Os dispositivos de Ethernet podem ser usados primariamente em pilotos e outras aplicações especiais, e eles adicionalmente podem ser ideais para certos ambientes intolerantes a RF de alta densidade, tais como armários de medidor.
Devido à complexidade aumentada no gerenciamento de uma interface de WAN, com suas exigências de negociação de enlace mais sofisticadas e pilha de TCP/IP (protocolo de controle de transmissão / protocolo de internet), os medidores conectados por WAN podem incluir uma placa de circuito adicional dedicada a uma conectividade de WAN.
Essa placa, caso usada, preferencialmente teria uma interface com o medidor 200 usando mensagens de EPSEM e o slot opcional 250.
A disponibilidade do slot opcional 250 no medidor 200 provê a vantagem de tornar o medidor 200 disponível para integração com backhauls de terceiros, tal como PLC (comunicações por linha de energia). De modo que esses dispositivos de terceiros sejam integrados no AMS 100, por outro lado, os dispositivos de terceiros precisarão incluir uma placa de comunicações e um relê em conformidade com C12.22 para acoplamento de sinais de comunicações a partir de qualquer rede proprietária de terceiros a uma conexão de IP. Alternativamente, os terceiros poderiam integrar o medidor 200 em sua própria solução de ponta a ponta.
O protocolo de comunicações entre o medidor 200 e os respectivos módulos de comunicações 230, 240 e o módulo de WAN ou o módulo de comunicações de terceiros opcional 250, seguem os padrões de C12.22, permitindo que quaisquer terceiros projetem conforme o padrão e tenham garantida uma integração relativamente direta.
A comunicação com o agente de coleta 190 é realizada por uma conexão de protocolo de Internet. A rede de área ampla é uma rede de IP plenamente roteável, endereçável que pode envolver uma variedade de tecnologias diferentes, incluindo, mas não limitando, GPRS, WiFi, WiMax, fibra, Ethernet privada, BPL, ou qualquer outra conexão com largura de banda suficientemente alta e capacidade de suportar uma comunicação por IP de duas vias plena. Várias hipóteses (isto é, critérios do presente assunto) podem ser feitas com referência à IP WAN. 0 agente de coleta 190 preferencialmente é implementado de modo a ser capaz de se comunicar diretamente com outros respectivos nós na IP WAN. Embora as comunicações possam ser conduzidas através de um firewall 194, não é necessário que elas sejam através de um proxy, a menos que o proxy seja em si um nó de C12.22 funcionando como um relê entre uma rede de IP privada e a IP WAN pública.
Ainda de acordo com o presente assunto, a interface entre medidores e o gerenciador de aplicativos (gerenciador de IMA) provido pela presente tecnologia facilita comunicações entre os dispositivos de nível superior incluindo, mas não limitando, o agente de coleta 190 e vários respectivos medidores e outros dispositivos no AMS 100. Mais particularmente, o Gerenciador de IMA usa um gerenciador de C12.22 para a criação de uma especificação de protocolo estendido para um objeto de mensagem de medidores eletrônicos (EPSEM) envolvido em um objeto de elemento de serviço de controle de aplicativo (ACSE), para o envio da mensagem para uma rede nativa, para recebimento de uma resposta a partir da rede nativa, e retornar um objeto de ACSE com a resposta de EPSEM embutida. O Gerenciador de IMA preferencialmente então utilizaria o IMA para a classe de dispositivo, de modo a se construir uma mensagem de EPSEM a ser enviada para os medidores.
O Gerenciador de IMA fundirá a mensagem de EPSEM com quaisquer ApTitles necessários para a formação de uma mensagem de ACSE e, então, passará a mensagem de ACSE para os medidores apropriados. Uma resposta a partir de um medidor será recebida a partir da rede no gerenciador de C12.22, o qual analisará gramaticalmente a mensagem de ACSE de modo a extrair o ApTitle e a mensagem de EPSEM. Por último, o gerenciador de C12.22 recebe uma resposta a partir de uma mensagem de ACSE prévia, analisa gramaticalmente a resposta de ACSE e a envia para o Gerenciador de IMA.
O Gerenciador de IMA processa uma resposta de exceção e a submete a um gerenciador de exceção, o qual entrega a exceção para todos os sistemas que tenham assinado aquele tipo de exceção. O Gerenciador de IMA utiliza um armazenamento de metadados para a recuperação de qualquer informação sobre o ApTitle chamando, tais como classe de dispositivo e arquivo de configuração de EDL, e, então, utiliza o IMA para a classe de dispositivo a interpretar, por exemplo, que uma falta ocorreu.
O Gerenciador de IMA informará o gerenciador de exceção qual respectivo medidor experimentou uma falta. O gerenciador de exceção obtém uma lista de assinantes para o tipo de exceção suprido a partir da API de armazenamento de metadados e, então, envia a mensagem para todo sistema de notificação que tenha assinado as notificações do tipo de exceção.
O sistema de medição avançado da presente tecnologia prove uma série (ou pluralidade) de serviços (funcionalidades) para serviços de utilidade pública. Em sua implementação mais básica, ele provê alimentações diárias de dados de intervalo residencial ou TOU (tempo de uso). Além dessa funcionalidade, ele provê notificações de falta e restauração de potência, leituras sob demanda, atualizações de firmware, controle de carga / resposta de demanda, leituras de medidor de gás e mensagens de exibição domésticas. Todas essas funções (serviços) são comunicados através do protocolo de C12.22. De modo a se otimizar o uso da RF LAN de largura de banda baixa, operações selecionadas assumem o uso de procedimentos de fabricante no medidor; contudo, o agente de comunicação de C12.22 geral do sistema não é especifico para quaisquer tabelas, dispositivos ou fabricantes em particular. No futuro, de acordo com o presente assunto, conforme substratos de rede alternativos se tornarem disponíveis, a RF LAN pode ser muito facilmente trocada por outras tecnologias.
Com a presente referência à Figura 3C, será visto que um emprego de exemplo de sistema de medição avançado de exemplo (AMS) geralmente 300 foi ilustrado. A Figura 3C ilustra para fins de exemplo apenas uma única célula de RF LAN, com doze respectivos nós membros organizados em três níveis, bem como quatro medidores de IP conectados diretamente 370, 372, 374, e 376. Nesse sistema, todos os respectivos dispositivos de metrologia 310, 320, 330, 332, 340, 342, 350, 352, 354, 356, 360, 362, 364, 466, 370, 372, 374, e 376, o relê de célula 302 e o agente de coleta 390 têm endereços de rede de C12.22. O agente de coleta 390 pode ter de acordo com o presente assunto múltiplos endereços de C12.22 para se permitir um endereçamento em separado entre diferentes serviços (funcionalidades). O sistema de gerenciamento de dados de medidor (ou mestres) 391 não faz parte da rede de C12.22, mas, preferencialmente será implementado de modo a se comunicar pela LAN de serviço de utilidade pública 392 para o agente de coleta 390 através de serviços da web. A comunicação entre o relê de célula 3 02 e a LAN de serviço de utilidade pública 3 92 variadamente envolve o backhaul público 390 e firewall 394, de uma maneira análoga àquela discutida acima em conjunto com o backhaul público 180 e o firewall 194 (Figura 3A) , assim como entendido por aqueles de conhecimento comum na técnica.
O processo de aquisição de dados de medidor começa com o sistema de gerenciamento de dados de medidor (ou mestres) 391 iniciando uma requisição por dados. Essa operação é feita através de uma chamada de serviços da web para o agente de coleta 390 e pode ser realizada sem conhecimento da funcionalidade configurada do dispositivo final. O agente de coleta 390 analisa a requisição por dados, e formula uma série de requisições de dados de multidifusão (ou difusão) de C12.22. Essas requisições então são enviadas diretamente para o dispositivo (no caso de um medidor conectado por IP, tal como 370) ou para o relê de célula 302 que retransmite a mensagem para fora para todos os nós apropriados. As mensagens de difusão e multidifusão são enviadas pelo relê de célula 3 02 para todos os membros da célula, através de uma difusão de nível de RF LAN de AMS, ou pelo relê de célula repetindo a mensagem. Em nome da eficiência, o uso de uma difusão de nível de RF LAN pode ser preferido.
Tipicamente, estas requisições são enviadas como uma chamada para um procedimento armazenado de fabricante. Em C12.22, as chamadas de procedimento armazenadas são realizadas como escritas em uma tabela predeterminada, por exemplo, a "tabela 7". O procedimento armazenado enviará a transferência (via upload) padrão para esse dispositivo.
Por exemplo, um dado medidor pode ser configurado para transferir (via upload) dois canais de dados de intervalo horário, mais seu histórico de evento. Um outro medidor poderia ser programado para enviar seus registradores de TOU. O procedimento armazenado requererá quatro parâmetros para ser plenamente operativo de acordo com o presente assunto: horário de começo de dados, horário de fim de dados, horário de começo de resposta e horário de fim de resposta. Os horários de começo e de fim de dados são usados para a seleção de quais dados enviar. O horário de começo e o horário de fim de resposta são usados para se determinar a janela dentro da qual o sistema à frente espera receber os dados. Os vários medidores habilitados de AMS da Figura 3C preferencialmente são programáveis no campo, através de tabelas de C12.22, quanto aos dados de tipo a serem incluídos em uma transferência (via upload) padrão.
Quando os dados são enviados para o agente de coleta 390, eles são enviados como uma auto-escrita de tabela de C12.19 com o bit de notificação regulado e o bit de não responder regulado. O resultado é que pelo presente assunto nenhum reconhecimento de C12.22 é enviado em resposta à difusão de agente de coleta, nem o agente de coleta 390 em resposta à notificação - escrita envia qualquer resposta; contudo, a notificação - escrita efetivamente serve pelo presente assunto como um reconhecimento para o recebimento da difusão.
A seção de processamento de resposta pode usar os dados configurados sobre um dispositivo final e a mensagem de resposta a partir do dispositivo final para a determinação dos resultados a partir do dispositivo. A seção de processamento de resposta começa uma operação associada a um serviço específico em uma lista de tarefa, mas pode ser comutada entre qualquer serviço ativo que esteja esperando uma resposta. Essa operação permite que respostas que contenham registros de eventos do dispositivo sejam analisadas gramaticalmente por cada serviço que poderia estar esperando por uma ação para ser completado no dispositivo final. Isso também permitiria que mensagens não solicitadas fossem analisadas gramaticalmente pelo código de IMA e, então, associadas mais tarde a quaisquer serviços possíveis, conforme determinado pelo IMA, tudo de acordo com o presente assunto.
Embora a maioria das operações não requeira isso, os medidores de AMS suportarão um encadeamento de uma série de mensagens de EPSEM, tais como múltiplas leituras e escritas de tabela em uma única requisição. Isto é uma funcionalidade que é requerida na especificação de C12.22, e ajudará na melhoria da eficiência do sistema, já que evita o tempo de processamento de envio de uma mensagem em separado para cada comando de EPSEM. Os dispositivos habilitados para AMS processarão cada requisição seqüencialmente, permitindo que uma série de operações seja manipulada em um único comando, cada uma fundamentada na próxima, de modo que uma leitura subseqüente a uma escrita reflita os resultados da escrita de requisição. Se um comando em uma cadeia de EPSEM não puder ser completado, os comandos remanescentes na cadeia serão rejeitados com mensagens de erro apropriadas, pelo presente assunto.
Quando um respectivo dispositivo recebe uma requisição, ele avalia o endereço de multidifusão especificado. Se o dispositivo for um membro do grupo de multidifusão, ele responderá à requisição; caso contrário, ele a descartará. A afiliação em diferentes grupos de multidifusão é determinada através do uso da tabela de padrão C12.22 122.
Uma leitura sob demanda pelo presente assunto é similar ao processo de aquisição de dados de medidor diariamente; contudo, ao invés de se enviar uma requisição de difusão ou multidifusão, o processo de leitura sob demanda de acordo com o presente assunto se comunica diretamente com os respectivos medidores desejados. Esse processo começa com um usuário iniciando uma leitura sob demanda através de uma interface de usuário de AMS, ou através de uma chamada de serviços da web a partir de um sistema à frente. Pelo presente assunto, uma camada de orquestração do agente de coleta 390 começa pela avaliação da carga de sistema atual do substrato de comunicações através do que o respectivo dispositivo é conectado. As requisições para uma leitura sob demanda de uma célula saturada podem ser rejeitadas.
Uma vez que o agente de coleta 390 determine que a requisição pode ser honrada, ele seleciona pelo presente assunto um servidor de comunicação apropriado no agente de coleta, e submete o comando para a recuperação de dados a partir do dispositivo e o retorna. O servidor de comunicações forma uma requisição de leitura de tabela de C12.22 e a envia para o dispositivo diretamente, se conectado por IP, ou para o relê de célula 302 para dispositivos conectados por RF LAN. Em casos em que o tráfego flui através da RF LAN, o software de relê de célula recupera a mensagem a partir do backhaul de IP 380, e avalia a mensagem. 0 endereço de destino (em terminologia de C12.22, o denominado ApTitle) pode ser retirado para se poupar largura de banda na rede, baseando-se, ao invés disso, no esquema de endereço de RF LAN subjacente para entrega da mensagem. O software de relê de célula também deve examinar se o ApTitle de destino ainda é válido na célula. Se o ApTitle de destino não for mais válido, o relê de célula rejeitará a mensagem, retornando um pacote de erro para o agente de coleta. Desde que o destino ainda seja válido, o software de relê de célula enviará a mensagem para o dispositivo através da RF LAN, pelo presente assunto.
Uma pilha de protocolo para a RF LAN vantajosamente toma a mensagem e constrói um percurso de nó para a mensagem a tirar, antes de realmente transmitir o pacote. Esse percurso de nó pré-construído permite que o relê de célula 302 pelo presente assunto empurre para baixo uma mensagem através da árvore da célula, sem a criação de mensagens de rádio redundantes. Se o agente de coleta 390 quiser fazer uma leitura sob demanda no medidor 356, ele começará pelo envio da mensagem para o relê de célula 302. O relê de célula 302 por sua vez enviará uma mensagem que será ouvida pelos respectivos medidores 310 e 320 (na configuração de exemplo da presente Figura 3C). O medidor 320 poderia ir à frente e retransmitir a mensagem, mas isto não faria a mensagem chegar ao medidor 356. Ao invés disso, simplesmente gastaria largura de banda. Com o percurso de nó provido pela pilha de protocolo de RF LAN, os medidores 310 e 320 ouvirão a mensagem, mas pelo presente assunto apenas o medidor 310 retransmitirá a mensagem. A mensagem retransmitida do medidor 310 será ouvida pelos medidores 330 e 332, mas apenas o medidor 332 estará no percurso de nó, de novo significando que outras partes da célula (tais como os medidores 350 r 3 53) não receberão uma mensagem que seria inútil para eles. Ambos os medidores 354 e 356 ouvirão a mensagem, mas ela é endereçada apenas ao medidor 356. Como tal, o medidor 354 pelo presente assunto simplesmente a ignorará.
Uma vez que a mensagem seja recebida no medidor em questão (isto é, pretendido), através de RF LAN ou através de IP, esse medidor deve desempacotar a requisição e atuar nela. O módulo de comunicações no dispositivo puxará a mensagem de C12.22 para fora do substrato de rede e a proverá para a placa de registrador 220 (Figura 3B) . A placa de registrador 220 desencriptará a mensagem com base nas chaves compartilhadas, e então responderá à requisição, encriptando-a e retornando-a para o ApTitle chamando. No caso da RF LAN, a mensagem é simplesmente encaminhada para a próxima camada acima na célula. As mensagens são encaminhadas a partir de uma camada para a próxima, até elas finalmente atingirem o relê de célula 302, o qual a retransmite através do backhaul de IP 3 80 para o servidor de comunicações que iniciou a transação.
A Figura 3D ilustra esquematicamente uma configuração de exemplo (representando a metodologia e o aparelho) para a implementação de uma ou mais transferências (via download) de acordo com a presente tecnologia. Embora para muitas finalidades a maior parte da discussão aqui se refira a essas transferências (via download) de firmware como um firmware novo ou atualizado, é para ser entendido que o presente assunto é igualmente aplicável e envolve plenamente quaisquer transferências (via download) de firmware, independentemente de sua caracterização. Por exemplo, poderia ser devido a circunstâncias e/ou necessidades em particular que o firmware fosse transferido (via download) por ou para um dispositivo em particular que fosse um retorno para uma versão prévia de firmware para esse dispositivo. Como um outro exemplo, poderia ser que a transferência (via download) de firmware para um dispositivo em particular fosse considerada como sendo a mesma versão do firmware ou uma versão corrigida do mesmo, presentemente residente e operando com esse dispositivo, como uma técnica para, com efeito, rebutar o dispositivo ou corrigir, de outra forma, algum assunto corrompido. Pretende-se que todas essas variações na constituição real e na caracterização da natureza e/ou das razões para as transferências (via download) em questão venham no espirito e no escopo do presente assunto.
Quando um firmware novo ou atualizado é para ser instalado em um sistema 400, uma imagem 410 do freqüente a ser transferido será provida para um agente de coleta de sistema de medição avançado (AMS) 412 como um arquivo de imagem binário. Uma discussão adicional sobre o agente de coleta 412 é incluída aqui, mas pelo presente é notado que o agente de coleta 412 é responsável pela ruptura da imagem binaria única em uma série 420 de blocos discretos 422 que podem ser distribuídos através de um arranjo de comunicações, tal como uma RF LAN, ou outra mídia. Em uma modalidade de exemplo, uma mídia em conformidade com C12.22 pode ser usada. Esses blocos 422 conterão uma prova (hash) ou uma soma de verificação para o bloco em si, para a verificação da integridade do bloco, bem como um identificador de bloco, o qual é representado na Figura 3D pelos espaços de começo e de fim 424 e 426, respectivamente.
Em geral, quando da transferência de blocos, cada um rompido, o bloco discreto 422 está em sua totalidade preferencialmente escrito em um registro em uma tabela de fabricante para imagens de firmware. Os dispositivos finais 440 são configurados para a avaliação desses blocos 422 para se determinar sua integridade discreta pelo uso de suas provas (hashes) de nível de bloco. Os dispositivos finais também podem validar que esses blocos 422 são montados (isto é, remontados) na ordem correta. Finalmente, cada dispositivo final é capaz de avaliar a integridade da imagem em geral pela avaliação da CRC (verificação de redundância cíclica) ou prova (hash) para a imagem inteira.
O presente processo básico para a transferência de blocos de imagem de firmware 422 envolve, em parte, uma funcionalidade que é similar àquela usada para a leitura de dados a partir de medidores. Uma difusão contendo os blocos de imagem 422 é enviada para os medidores 440. Os medidores 440 indicam, de uma maneira descrita adicionalmente aqui, que eles receberam de forma bem sucedida os blocos de imagem 422. Os medidores que não respondem são tentados de novo em um processo de recuperação para a compensação de quaisquer falhas. Devido à natureza critica de imagens de firmware, e ao grande número de blocos envolvidos, alguns mecanismos de controle e de retorno adicionais podem ser desejados em alguns casos, para se lidar de forma logística com o volume de tráfego.
O gerenciamento do transporte de blocos de firmware 422 em um ambiente o qual encontra ou envolve mídia não confiável se torna crítico quando da transferência de imagens de firmware. Em uma configuração de exemplo, uma imagem de firmware de 384 k dividida em blocos de 64 bytes requererá que 6.144 blocos sejam transferidos completamente de forma bem sucedida, antes de poder ser carregada. Quando da transferência de blocos através de uma RF LAN, por exemplo, é relativamente provável que pelo menos um nó em uma dada célula falhe em receber de forma bem sucedida um bloco. Essas circunstâncias presentemente são endereçadas de duas maneiras chaves. Em primeiro lugar, é importante que os blocos sejam capazes de ser transmitidos e recebidos em qualquer ordem. Em segundo lugar, dependendo da confiabilidade prática da rede subjacente, de acordo com o presente assunto, em alguns casos pode ser praticado difundir um dado bloco várias vezes, antes de se recorrer a transferências de ponto a ponto de blocos de imagem. Em uma configuração de exemplo, foi descoberto que sistemas de nível mais alto, isto é, o agente de coleta 412 e/ou um relê de célula 430, preferencialmente devem transmitir a imagem de firmware pelo menos duas vezes e, em alguns casos, três ou quatro vezes, antes de se recorrer a uma transferência de ponto a ponto de blocos de imagem.
Com referência adicional à Figura 3D, um processo de transferência (via download) de firmware começa com o agente de coleta 412 enviando uma mensagem de difusão para todos os nós alvos, chamando um procedimento armazenado de fabricante ou escrevendo em uma tabela de fabricante no dispositivo. Nesse contexto, um nó alvo pode corresponder a um dispositivo final tal como o medidor 448, o relê de célula 430 ou os medidores 440 incluindo medidores representativos 442, 444 e 446. Esse comando indica para o dispositivo o número de blocos de firmware que deve esperar receber, e que agora deve estar no modo de transferência de (via download) de firmware.
Quando nesse modo de transferência de (via download) de firmware, o dispositivo reportará o número de blocos que recebeu de forma bem sucedida como parte de quaisquer requisições de leitura diárias. Adicionalmente, ser colocado no modo de transferência de (via download) de firmware reinicializa para zero um contador de bloco desse dispositivo. Mais ainda, o comando inclui instruções para os dispositivos finais indicando que nenhum reconhecimento direto da parte dos medidores deve ser feita. Ao invés disso, os dispositivos reconhecem esse comando pelo relatório de sua contagem de sucesso como parte do próximo ciclo de interrogação.
O agente de coleta 412 é responsável pela avaliação, com base na presença da contagem de sucesso de bloco de firmware, se todos os nós alvos entraram de modo bem sucedido no modo de transferência de (via download) de firmware. Os nós que não foram comutados para o modo de transferência de (via download) de firmware eventualmente então serão individualmente contatados pelo agente de coleta 412.
Uma vez que os nós alvos estejam no modo de transferência de (via download) de firmware, o agente de coleta 412 começará a difundir os blocos de firmware 422 para os nós alvos 440. Como uma alternativa para a transferência dos blocos de firmware 422 exclusivamente pelo agente de coleta 412, pode ser desejável transferir a imagem de firmware 410 para os relês de célula 430 e, então, enviar um comando instruindo-os para difundirem a imagem de firmware 410 na sua respectiva célula. Esse método alternativo seria uma abordagem para a redução dos custos de backhaul público de concessionária e para se permitir que os relês de célula gerenciem melhor a largura de banda nas suas células.
Uma conclusão das transferências de difusão é um processo que pode levar vários dias ou mesmo semanas, dependendo de ser feito em conjunto com outras operações. Em qualquer caso, após essa conclusão, o agente de coleta 412 começa a avaliar a contagem de sucesso de bloco de cada um dos nós alvos. Quando um nó tiver completado um conjunto de blocos, ele gravará um evento especial no registro de eventos de histórico de medidor indicando essa conclusão bem sucedida. A maioria dos nós deve ter um conjunto completo de blocos uma vez que as transferências de difusão estejam completadas. Os nós que ainda estejam faltando precisarão tê-las transferidas ponto a ponto. Os nós que tenham blocos excessivos faltando após o processo de difusão ser completado podem ser indicados com um indicador tipo de flag quanto a uma possível manutenção ou substituição, como estando potencialmente defeituosos. Para facilitação das transferências de ponto a ponto, o agente de coleta 412 chamará um segundo procedimento armazenado no dispositivo. Esse segundo procedimento, um procedimento armazenado de fabricante, proverá uma lista de blocos faltando, por número de bloco. Em uma modalidade de exemplo, a lista de bloco incluirá um número máximo predeterminado de blocos e um byte de status indicando se há mais do que o número predeterminado de blocos faltando.
Por exemplo, o número máximo predeterminado de blocos pode ser regulado para vinte blocos. No uso desse método, a maioria dos medidores receberá todos os blocos e não precisará reportar blocos individuais; contudo, aqueles medidores que forem blocos faltando poderão ser interrogados quanto a uma manifestação do que eles ainda requerem.
O agente de coleta 412 usará esses dados de bloco faltando providos pelo respectivo medidor 440 para a realização de transferências de bloco de ponto a ponto. Os nós de medidor que não puderem ser contatados serão reportados pela operadora do sistema. Uma vez que novas tentativas ponto a ponto tenham sido completadas, os dispositivos podem ser instruídos para habilitarem o novo firmware. O comando para ativação do firmware pode corresponder a um procedimento armazenado de fabricante de C12.22. Se uma data e um horário forem especificados, o dispositivo ativará o firmware na data e no horário especificados. Se nenhuma data ou horário for provido, o dispositivo normalmente será regulado para ativar a transferência (via download) de firmware em uma base imediata. Uma ativação de firmware bem sucedida pode envolver dois aspectos adicionais. Em primeiro lugar, dispositivos de metrologia selecionados, isto é, medidores, podem empregar não apenas um, mas uma pluralidade de imagens relacionadas a diferentes aspectos da operação do dispositivo. Em uma configuração de exemplo, pelo menos três imagens de firmware separadas podem ser empregadas: uma para a placa de registrador de medidor, uma outra para um microprocessador de rede de área local (LAN) de vizinhança e uma terceira para um processador de rede de área doméstica (HAN) . Em uma configuração de exemplo mais específica, o microprocessador de rede de área local de vizinhança pode corresponder a um processador de ZigBee. Cada um desses componentes terá sua própria imagem de firmware que pode precisar ser atualizada. Adicionalmente, no decorrer do tempo, novas versões de dispositivo de metrologia as quais requerem diferentes firmwares podem ser incorporadas nos sistemas existentes. Nesse caso, uma dada célula pode ter uma mistura de dispositivos com necessidades diferentes de firmware. Por exemplo, o protocolo de ZigBee pode ser usado para comunicação com medidores de gás, visores domésticos, relês de controle de carga e termostatos domésticos.
Com referência presentemente à Figura 3E, é ilustrada e representada uma metodologia de exemplo (e um aparelho correspondente) para a transmissão de diferentes imagens de firmware para dispositivos finais selecionados. Conforme ilustrado na Figura 3E, para o grupo geral de medidores 440 ilustrados, um primeiro conjunto desses medidores ilustrado com um fundo branco (e geralmente representados pelos medidores 460, 462, 4 64, 466, e 468) suportam uma imagem de firmware, enquanto um segundo subconjunto de medidores geralmente ilustrados 44 0 ilustrados com um fundo cinza (e geralmente representados pelos medidores 450, 452, 454, 456, e 458) suporta uma outra imagem de firmware. Como resultado, embora os medidores 462, 464 estejam abaixo dos medidores 450, 452 na hierarquia de rede de célula (ou árvore) e possam ser capazes de trocar imagens de firmware com outros, a única forma pela qual os medidores 4 62, 4 64 podem receber seu firmware é através dos medidores 450, 452, os quais no presente exemplo são de um outro tipo de dispositivo.
De modo a se lidar com essas circunstâncias de exemplo, conforme representado na presente Figura 3E, o sistema de distribuição de imagem de firmware é independente do dispositivo real para o qual o firmware é pretendido. Dito de uma outra forma, quando uma imagem é entregue para o relê de célula 430 e distribuída pela RF LAN, é distribuída para todos os membros da célula que combinam o endereço de difusão ou multidifusão usado, independentemente de a imagem ser compatível com seu hardware em particular. Isto significa que de acordo com a presente tecnologia, os membros de célula atuam como computadores centrais para o firmware. De modo a se atualizarem ambos os tipos de medidores (pelo presente exemplo representativo) , duas atualizações de firmware precisarão ser distribuídas. O firmware será transferido primeiramente para os medidores do primeiro conjunto (geralmente representado pelos medidores 460, 462, 464, 466, e 468) e, então, ativado. Em segundo lugar, o firmware será transferido para medidores do segundo subconjunto (geralmente representado pelos medidores 450, 452, 454, 456, e 458) e, então, ativado. Esse mesmo mecanismo pode ser usado para a transferência (via download) de imagens de firmware separadas para microprocessadores individuais no nó final, conforme necessário em uma base caso a caso por uma implementação específica do presente assunto.
Vantajosamente, de acordo com o presente assunto, o código de ativação de firmware não apenas avalia a integridade dos blocos individuais e a imagem de firmware em gral, mas também verifica se a imagem é aplicável para seu hardware real e para qual hardware é direcionado. Em geral, o comando de ativação será enviado apenas para os dispositivos apropriados pelo uso de um grupo de multidifusão associado à classe de dispositivo. Não obstante, checar se a imagem é compatível com o dispositivo final é uma salvaguarda apropriada praticada em algumas modalidades de acordo com o presente assunto.
Com referência novamente a ambas as Figuras 3D e 3E, será observado que os vários medidores ou nós 440 são ilustrados como sendo conectados uns aos outros por linhas de seta de cabeça dupla (ilustrados de forma representativa em 470, 472, 474, 476, e 478 na Figura 3D, e em 480, 482, 484, 486, e 488 na Figura 3E). Essas interconexões ilustram esquematicamente uma rede autogerada formada pelos medidores 440 em si pelo presente assunto, em consonância com cada outro e o relê de célula 430, conforme os medidores individuais 440 forem ativados. Devido ao fato de cada um dos respectivos medidores 440 ser independente com respeito à RF LAN formada, existe uma oportunidade para a distribuição de um software (firmware) de atualização dentre os vários medidores em uma base par a par viral.
No modelo de par a par viral precedente, uma imagem de firmware pode se entregue para o relê de célula de exemplo 430. A partir dali, o agente de coleta 412 preferencialmente pode enviar um comando de procedimento armazenado para o relê de célula 430, indicando que ele deve distribuir essa imagem de firmware para a RF LAN. O agente de coleta 412 também enviará um comando para os nós de medidor na célula usando uma mensagem de difusão ou de multidifusão, instruindo-os que uma nova imagem de firmware está disponível. Uma vez que o comando como esse seja recebido, o relê de célula 430 torna disponível o firmware para seu processador de RF LAN local. Pelo presente assunto, os nós de medidor 440 nessa célula instruem seus processadores de RF LAN para começarem a procurarem blocos. Nesse ponto, os processadores de RF LAN assumem o processo de transferência de bloco. De novo, pela presente metodologia previamente discutido, esses blocos 422 podem ser enviados em qualquer ordem.
Esse mecanismo de distribuição de tipo viral mostrado presentemente pode ser muito potente e muito eficiente pelo fato de poder ser capaz de fazer melhor uso da largura de banda física disponível. Segundo esse arranjo de par a par presente viral, nós de medidor individuais 44 0 podem pegar imagens de firmware ou porções de imagens de firmware de seus vizinhos ou pais imediatos, ao invés de precisar pegar os dados diretamente do relê de célula 430 ou do agente de coleta 412. Como resultado, uma porção da célula poderia estar trocando blocos de firmware enquanto uma outra porção da célula poderia estar passando várias mensagens entre nós de medidor 140 e o relê de célula 130, tudo sem impacto em cada outro.
Com referência à Figura 3F, é ilustrada uma representação de diagrama de blocos dos componentes de exemplo do agente de coleta 412 de acordo com uma modalidade de exemplo do presente assunto. O agente de coleta 412 é uma coleção de funcionalidade baseada em software, que provê serviços de C12.22 de ANSI para os dispositivos que compreendem a rede de C12.22, incluindo um ou mais relês de célula 430, bem como os dispositivos de metrologia e finais 440. Embora esses componentes sejam preferencialmente baseados em software, aqueles de conhecimento comum na técnica apreciarão várias formas equivalentes de implementação, provendo a mesma funcionalidade. Conceitualmente, o agente de coleta 412 é compreendido por três componentes principais, o sistema ou gerenciador de orquestração geralmente 520, o computador central de relê mestre / autenticação 510 e o servidor ou os servidores de comunicações (representados pelos componentes ilustrados 512, 514 e 516). O agente de coleta 412 é implementado preferencialmente de modo a ser capaz de distribuir o trabalho dentre múltiplos servidores 512, 514 e 516, de modo a se facilitar um escalonamento.
Em um sistema de C12.22, o relê mestre 510 é o processo de coordenação para o sistema em geral. De modo a se enviarem ou receberem mensagens de C12.22, os respectivos nós 440 devem ser registrados junto ao relê mestre. Contudo, antes de um respectivo nó ter permissão para se registrar, ele deve ser autenticado. O computador central de autenticação prove essa funcionalidade na presente modalidade de exemplo. O relê mestre ou estação é responsável pelo processo de aquisição de dados de medidor real, em comunicação com o medidor através de mensagens de C12.22.
Conforme será entendido por aqueles de conhecimento na técnica, cada um dos respectivos componentes principais do agente de coleta 412 por sua vez é constituído por uma série de componentes menores e conjuntos de recurso de funcionalidade. 0 gerenciador de orquestração ou camada 520 prove uma coordenação entre esses componentes, e apresenta uma API única unificada (interface de camada de aplicativo) para sistemas à frente. 0 gerenciador de orquestração ou sistema 520 roda um serviço (ou funcionalidade) único de orquestração mestre e uma série de agentes. Cada servidor físico separado terá um agente de orquestração para se ligá-lo ao sistema maior. As requisições de API são dirigidas a um serviço (ou funcionalidade) de orquestração mestre, o qual, por sua vez, trabalha com os agentes de orquestração para garantir que o trabalho requisitado ou a metodologia seja realizado ou executado.
O relê mestre / computador central de autenticação 510 proverá serviços / funcionalidade de registro de C12.22 padronizados bem como uma funcionalidade / serviços de autenticação de rede de C12.22 integrados. Uma visão para o protocolo C12.22 é que, similar ao DNS (servidores de nome de domínio) , um relê mestre de C12.22 pode ser criado, o qual seria compartilhado entre múltiplos serviços de utilidade pública, talvez provendo serviços para uma região inteira ou um país. Com essa abordagem em mente, a implementação de um relê mestre de acordo com a presente tecnologia deve prover pleno suporte para o uso de outros computadores centrais de autenticação, e para o envio de mensagens de notificação para os computadores centrais registrados. Adicionalmente, o gerenciador de orquestração ou camada 520 preferencialmente é implementado de modo a ser capaz de receber notificações de relês mestres de outros fabricantes, significando que uma implementação do presente assunto poderia ser realizada empregando um relê mestre a partir de uma fonte externa.
Os servidores de comunicações representativos 512, 514 e 516 provêem uma funcionalidade de comunicação com dispositivos, tal como para uma análise gramatical e tradução dessas comunicações e postar ou retornar dados conforme necessário. Os servidores de comunicação 512, 514 e 516 assim preferencialmente podem compreender uma série de serviços / funcionalidade para a realização dessa funcionalidade em geral pelo presente assunto. Em servidores de comunicações 512, 514 e 516 há uma série de componentes principais: um computador central de comunicações de medidor, um spooler de dados, e um gerenciador de evento de exceção. 0 computador central de comunicações de medidor é responsável por ouvir comunicações de rede e envio de comunicações de rede. É o componente que "fala" por C12.22 e "interpreta" os dados de tabela de C12.19. 0 spooler de dados e o gerenciador de evento de exceção provêem mecanismos para a transmissão continua de dados de medição e eventos de exceção, respectivamente, para sistemas à frente.
A Figura 4 mostra pelo presente assunto um exemplo de um quadro inteiro do protocolo em questão para uma mensagem de enlace ascendente, isto é, mensagens de dados enviadas a partir de um ponto final sincronizado para uma relê de célula. Cada campo é explicado aqui pela seção de descrição de quadro para cada respectiva camada.
Pelo presente assunto, há várias camadas físicas propostas. Todas usam uma técnica de espectro de dispersão de salto de freqüência. Cada uma delas é pretendida para ser usada para uma localização de mercado específico (para a América do Norte ou para a Europa) e dentro de uma banda específica, e segue os regulamentos requeridos regionais ou locais.
A camada física denominada PHY-FHSS-NA-915 é pretendida para ser usada na banda de ISM de 902 a 928 MHz na América do Norte. Ela está em conformidade com os regulamentos pertinentes da FCC, especificamente as partes 15.35, 15.205, 15.209, e 15.247, e em uma modalidade preferida podem envolver 52 canais. Outras particularidades das especificações de transmissor e de receptor para essa banda de 915 MHz, para a América do Norte, bem como as alocações de canal dos mesmos, são bem conhecidas por aqueles de conhecimento comum na técnica, a partir dos regulamentos pertinentes, sem requerer uma discussão adicional com isso.
A camada física denominada PHY-FHSS-NA-2400 é pretendida para ser usada na banda de ISM de 2,4 GHz na América do Norte. Ela está em conformidade com os regulamentos pertinentes da FCC, especificamente as partes 15.35, 15.209, 15.247 e 15.249, e em uma modalidade preferida podem envolver 16 canais. Outras particularidades das especificações de transmissor e de receptor para essa banda de 2,4 GHz, para a América do Norte, bem como as alocações de canal dos mesmos, são bem conhecidas por aqueles de conhecimento comum na técnica, a partir dos regulamentos pertinentes, sem requerer uma discussão adicional com isso.
A camada física denominada PHY-FHSS-EU-868 é pretendida para ser usada na banda de ISM de 8 68 MHz na União Européia. Ela está em conformidade com os regulamentos pertinentes da ETSI, especificamente as seções 300 220 e ERC 70-03. Outras particularidades das especificações de transmissor e de receptor para essa banda de 868 MHz na União Européia são bem conhecidas por aqueles de conhecimento comum na técnica, a partir dos regulamentos pertinentes, sem requerer uma discussão adicional com isso.
A camada física denominada PHY-FHSS-EU-2400 é pretendida para ser usada na banda de ISM de 2,4 GHz na União Européia. Ela está em conformidade com os regulamentos pertinentes da ETSI, especificamente as seções 300 228 e ERC 70-03 e, em uma modalidade preferida, pode envolver 16 canais. Outras particularidades das especificações de transmissor e de receptor para essa banda de 2,4 GHz na União Européia são bem conhecidas por aqueles de conhecimento comum na técnica, a partir dos regulamentos pertinentes, sem requerer uma discussão adicional com isso.
Com referência à camada PHY, isto descreve os parâmetros ajustáveis (isto é, "passíveis de tweak") (tweak são dicas para otimizar o desempenho de um sistema operacional, alterar características de um programa, configurar opções escondidas, etc.) dessa camada PHY. Para PHY_Synch_Length: o comprimento em bits do campo Synch, a seqüência de bit de sincronização da PPDU. Para PHY_SFD_Value: o valor do campo de SFD da PPDU. Este valor deve ser escolhido com propriedades de autocorrelação apropriadas para se permitir uma detecção confiável de começo de quadro. Os valores recomendados são dados na tabela a seguir. 0 bit mais significativo do PHY_SFD_Value é enviado primeiramente na interface de ar, imediatamente após o preâmbulo. Estes valores de SFD têm ortogonalidade suficiente para serem usados com a finalidade de isolamento de várias redes coexistentes. Para PHY_RSSI_Average_Time: o tempo médio para a realização da leitura de RSSI.
<table>table see original document page 102</column></row><table>
Os valores padrões de parâmetro de PHY preferencialmente podem ser considerados conforme se segue.
Para PHY_Synch_Length: 32 bytes; para PHY_SFD_Value: 0xB127 (com o bit mais significativo sendo enviado primeiramente na interface de ar); e para PHY_RSSI_Average_Time: 1 ms.
Quanto a parâmetros de acesso a meio, divisões de tempo e de freqüência são gerenciados com o uso da técnica de Aloha com intervalo (cujos detalhes são bem conhecidos por aqueles de conhecimento comum na técnica). O tempo geralmente é dividido em intervalos de tempo (TS) idênticos e em cada mudança de TS (intervalo de tempo), a freqüência salta de um canal para um outro canal de acordo com uma seqüência de salto de freqüência. A camada de MAC está encarregada da sincronização. Uma vez que tipicamente o tráfego em qualquer ponto no tempo é lento, a técnica de Aloha com intervalo é uma seleção apropriada. Cada medidor por padrão está no modo de receptor e empurra os dados no meio quando ele quiser falar. Esse método geralmente pode estar produzindo um número relativo de colisões, mas, em condições de operação normais, espera-se que as colisões sejam mais baixas do que as colisões devido ao ambiente com ruído de bandas de ISM. Contudo, o presente protocolo intencionalmente gerencia repetições para compensação desse fenômeno.
A camada física pode proporcionar às camadas acima dela um instantâneo da qualidade de enlace entre o ponto final e o remetente da mensagem. A camada física faz isso pela medição do Indicador de Intensidade de Sinal Recebido (RSSI) durante a recepção de mensagem. Essa leitura é processada durante a recepção dos bits de sincronização, os quais são uma seqüência alternada de zero e um. Isto é uma leitura média por PHY_RSSI_Average_Time ms. Quando a camada física detecta o começo de delimitador de quadro, ela pára a leitura de RSSI e salva o valor para proporcioná-lo mais tarde para a camada de MAC em conjunto com a mensagem recebida.
O RSSI também é uma medição do nível de interferência em um dado canal quando usado fora da recepção de uma presente mensagem de rede de protocolo. Isto é usado, por exemplo, nos processos de análise de ambiente.
Em todos os casos, o valor de RSSI enviado para a camada de MAC pela camada física preferencialmente não é uma mera leitura do registrador de RSSI de um grupo de chips de transceptor. 0 valor preferencialmente é processado para refletir o nível de potência real do sinal entrando, isto é, um ganho de LNA e perdas de inserção de filtro devem ser levados em consideração no valor de RSSI encaminhado para a camada de MAC.
O RSSI é formatado como um byte sinalizado único. 0 valor é dado em dBm. Sua faixa teórica, portanto é de -128 dBm a +127 dBm.
Os dados preferencialmente são transmitidos no formato terminal pequeno (o bit menos significativo primeiro). Uma ordenação de bit também é feita com o bit menos significativo primeiro.
A correção de erro antecipada (FEC) usada pela camada física é um código de Reed-Solomon entrelaçado (32, 38) com símbolos no Campo de Galois (GF) (256) . As etapas para codificação são:
• Se o comprimento de MPDU for maior do que 2 8 bytes, dividir a MPDU em N blocos de 28 bytes. Se o comprimento de MPDU não for um múltiplo de 28, o último bloco será mais curto.
• Para cada um destes blocos, computar os 10 bytes de redundância com o código de RS (38.28) . Se necessário, o último bloco é preenchido com zero para se permitir o uso do mesmo algoritmo de computação para todos os blocos. • Escrever os blocos de dados e os bytes de redundância na tabela de entrelaçamento. Cada bloco ocupa uma linha nesta tabela.
• Construir a LPDU começando a partir da primeira coluna da tabela de entrelaçamento e terminando com o último.
Os zeros introduzidos no último bloco servem à finalidade de codificação apenas, eles não são enviados na interface de ar. O campo de comprimento do cabeçalho de PHY inclui a FEC, mas não inclui o preenchimento com zeros, é computado com:
Comprimento = 38 * N - (número de zeros adicionados no bloco N)
A Figura 5 ilustra a fragmentação da MPDU em blocos antes da codificação de Reed-Solomon; em outras palavras, a Figura 5 mostra blocos de dados para uma codificação / decodificação de FEC.
A Figura 6 mostra uma presente estrutura de tabela de entrelaçamento de exemplo para codificação / decodificação de FEC. Esse entrelaçamento é feito no sentido de byte, isto é, o primeiro byte de bloco 1 é enviado, então, o primeiro byte de bloco 2. Essa operação é continuada até o último byte de FEC ser enviado. Após essa codificação de Reed-Solomon e um entrelaçamento, os bytes de redundância estão no fim do quadro, conforme mostrado pela presente Figura 7.
As etapas para a decodificação são as mesmas para essa codificação, mas em ordem inversa:
• Preencher a tabela de entrelaçamento começando com a primeira coluna. A partir do campo de comprimento do cabeçalho de PHY e do tamanho de bloco, é possível conhecer onde o preenchimento com zeros precisa ser inserido.
• Para cada linha na tabela de entrelaçamento, corrigir os erros com o código de RS (38, 28).
· Retirar a FEC e remontar a MPDU.
A codificação de Reed-Solomon preferencialmente usada no presente protocolo é um código de RS (38, 28). É uma versão resumida de um código de RS (255, 245) com símbolos em GF (256). Isto significa que os símbolos do código são bytes e que para cada bloco de 28 bytes, são apensados 10 bytes de redundância adicionais. Este código tem uma distância de Hamming de 11 e permite a correção de 5 bytes errôneos por bloco.
Mais particularmente, cada byte da mensagem é considerado como um elemento de GF (256). Uma referência aqui a esses problemas será como símbolos. Todas as operações feitas com esses símbolos (adição, subtração, multiplicação e divisão) devem ser feitas de acordo com as leis aditivas e multiplicativas do campo de Galois GF (256), construído com o polinômio primitivo p(x) = x8 + x7 + χ2 + χ + 1. Um símbolo de GF (256) tem várias representações úteis: uma representação binaria {b7b6b5b4b3b2bibo} , uma representação polinomial b7a7 + b6a6 + b5as + b4a4 + b3a3 + b2a2 + bia + b0 e uma representação exponencial am. Nas últimas duas representações, α é um elemento primitivo de modo que ρ (a) =0. A representação binária ou polinomial é útil para a adição e a representação exponencial é útil para multiplicação. Todos os elementos de GF (256), exceto por zero, têm uma representação exponencial, o campo completo pode ser escrito como o conjunto GF (256) = {0, 1, a, a2, a3, ..., a253 , a254 }. A conversão entre as duas representações é feita com uma tabela de consulta. Para a implementação do codificador / decodificador, é necessário adicionar e multiplicar os símbolos em GF (256) . Uma adição é prontamente realizada com a representação binaria ou polinomial dos símbolos. A operação é equivalente a uma adição de módulo 2 de cada bit, por exemplo:
0010 1100 + 1000 1111 = 1010 0011
A multiplicação é relativamente mais difícil porque uma conversão para a forma exponencial do símbolo é necessária. Uma tabela de consulta preferencialmente é usada para essa finalidade. Como um exemplo, uma multiplicação a seguir dos dois símbolos do exemplo prévio:
0010 1100 χ 1000 1111
0 primeiro símbolo (44) tem a representação exponencial α190, o segundo símbolo (143) tem a representação exponencial α90. O produto é a190a90 = a280 = a255+25 = α25, porque a255 = 1. Essa tabela pode ser usada de outra forma para conversão do resultado em forma binária e
obter 44 * 143 = 226.
Com referência ao presente codificador de Reed- Solomon, conforme implementado preferencialmente de acordo com o presente assunto, conformando-se à convenção estabelecida na teoria de codificação, poder-se-ia usar aqui a representação polinomial para as mensagens. Isto significa que o presente bloco de dados de 28 símbolos, {u27, u26, u25, ..., U1, u0}, pode ser escrito u(x) = u27x27 + U26X26 + U3X3 + u2x2 + U1X + u0. 0 símbolo U27 é o primeiro símbolo escrito na tabela de entrelaçamento, a qual é preenchida da esquerda para a direita. A palavra de código de 38 símbolos (mensagem + símbolos de redundância) pode ser escrita c (x) = c37x37 + c36x36 + c3x3 + c2x2 + C1X + c0. O processo de codificação de Reed-Solomon é equivalente a uma divisão da mensagem por um polinômio gerador G(x). Isto pode ser implementado com um registrador de deslocamento de retorno linear, conforme mostrado na presente Figura 8. Isto é similar a, mas diferente de um codificador de CRC convencional. A diferença é que no presente assunto cada multiplicação por um coeficiente e cada adição têm que ser entendidas como multiplicação e adição no GF (256).
Na implementação de registrador de deslocamento representada na presente Figura 8, os gi são elementos de GF (256). O registrador de deslocamento é primeiramente inicializado com zeros. Os símbolos da mensagem então são deslocados para o registrador, começando com u27 e terminando com u0. Após o bloco de dados inteiro ter sido empurrado para o registrador de deslocamento, o conteúdo do registrador é o resto da divisão. Estes símbolos são os símbolos de FEC e eles são apensados à mensagem inicial da forma a seguir:
<formula>formula see original document page 108</formula>
Como com a computação de CRC convencional, os fatores multiplicativos no registrador de deslocamento são dados pelos coeficientes de um polinômio:
<formula>formula see original document page 108</formula>
Em nosso caso, este polinômio é:
<formula>formula see original document page 108</formula>
Uma vez que esse polinômio seja desenvolvido para se encontrarem os coeficientes gi, o resultado é:
<formula>formula see original document page 109</formula>
A primeira etapa do processo de decodificação de Reed- Solomon é a sindrome de computação. Para um bloco recebido de 38 bytes, 10 síndromes preferencialmente são computadas. Se a mensagem recebida for {r37/ r36, ..., r2, T1, r0}, a representação polinomial a seguir se aplicará:
<formula>formula see original document page 109</formula>
As 10 síndromes {S1, S2, ... S10) serão computadas com R(x), conforme mostrado abaixo:
<formula>formula see original document page 109</formula>
Se as 10 síndromes forem iguais a zero, não haverá um erro detectável na mensagem e o processo de decodificação parará aqui. Obviamente, há uma possibilidade de um erro indetectável, mas, preferencialmente, isto será detectado pela CRC.
A segunda etapa do processo de decodificação de Reed- Solomon é a computação do polinômio localizador de erro. Este polinômio tem a forma a seguir:
<formula>formula see original document page 109</formula>
O grau desse polinômio não é conhecido de antemão, porque depende do número de erros na mensagem recebida. Para a computação dos coeficientes de ELP(χ), um algoritmo iterativo é usado, o algoritmo de Berlekamp-Massey. Uma descrição de pseudocódigo desse algoritmo é conforme se segue: <formula>formula see original document page 110</formula> Uma vez que o polinômio localizador de erro tenha sido computado, as raízes desse polinômio são encontradas. Para se encontrarem as raízes, ELP(x) é computado para todo ζ não nulo em GF (256), até ν raízes serem encontradas, onde ν é o grau do polinômio localizador de erro. Se menos de ν raízes forem encontradas, os erros serão incorrigíveis e o pacote inteiro deverá ser rejeitado. O inverso das raízes de ELP(x) é denominado os localizadores de erro. Um localizador de erro indica a posição de um erro na mensagem, conforme se segue.
<formula>formula see original document page 111</formula>
é o localizador de erro
if X = α^k , o símbolo na posição k é corrompido Como um exemplo, é encontrado que ELP (a235) = 0, a"235 é um localizador de erro. 0 inverso de a235 é computado, o qual é a"235 = a255cT235 = a20. É concluído nessa instância de exemplo que o símbolo na posição 20 está corrompido, isto é, que X2Q na seqüência {r37, r36, ..., r2, Tll r0}. Neste estágio do processo de decodificação, se o padrão de erro for corrigível, as posições de todos os símbolos corrompidos no bloco serão conhecidas. O conjunto de localizadores de erro é:
{x1,x2,...xv} ELP(X1"]) = Q
Uma técnica presente para se acelerar potencialmente a computação das raízes de ELP(x) é tentar apenas os elementos de GF (256) que apontem para erros no bloco, isto é: {1, a"1, a"2, a"3, ..., a"37}.
A próxima etapa preferencialmente pelo presente assunto é corrigir os erros. Isso envolve a computação do polinômio avaliador de erro, definido pelo seguinte:
EEP(x) = S(x)ELP{x) mod(x10)
onde um novo polinômio é introduzido, cujos coeficientes são as síndromes
S(x) = S1 + S2X + S3X2 +- - + S10X9
O mod(x10) na definição de EEP (x) significa que todos os termos do grau 10 ou mais altos são descartados. Também envolve o uso de um polinômio denominado a derivada formal do polinômio localizador de erro, conforme se segue:
DER _ ELP(x) = ELP1 + ELP3X2 + ELP5X4
O erro no símbolo indicado pelo localizador de erro Xk é dado por:
<formula>formula see original document page 112</formula>
O símbolo corrigido é:
Novo valor de símbolo = valor antigo de símbolo + Error(k)
O formato do quadro de camada física é representado pela presente Figura 9. O campo de Synch do Preâmbulo (veja a Figura 9) do quadro de camada física é composto por uma seqüência de zero e um alternados. É pretendido permitir que o receptor remoto detecte a presença de uma mensagem entrando e realize uma recuperação de relógio de dados. Ele indica um quadro iminente e vantajosamente também é usado pelo receptor para a medição da intensidade de potência (RSSI) do sinal recebido. O comprimento de campo Synch é dado pelo parâmetro de camada PHY PHY_Synch_Length. O valor padrão para este parâmetro é de 32 bits (4 bytes).
O campo de começo de delimitador de quadro (SFD) (veja a Figura 9) é de dois bytes de comprimento. Ele sinaliza o final do preâmbulo e o começo do cabeçalho de PHY. Ele tem um valor fixo pré-definido dado pelo parâmetro de camada PHY PHY_SFD_Value. Se várias redes operadas por diferentes serviços de utilidade pública coexistirem na mesma área, é possível pelo presente assunto atribuir um valor de SFD específico a cada rede. Como apenas os pacotes com o valor de SFD direito são considerados, isto impedirá um ponto final de processar os pacotes pretendidos para uma outra rede. Quando usado em conjunto com a ID de serviço de utilidade pública, este recurso vantajosamente aumenta o número possível de redes coexistentes na mesma área.
Mais ainda pelos presentes recursos, como uma opção a detecção de SFD pode ser configurada pelo presente assunto para aceitação do pacote apenas se 15 dos 16 bits combinarem com o PHY_SFD_Value. Quando usada com FEC, essa alternativa serve para aumento da imunidade a ruído pelo presente assunto.
Com referência ao cabeçalho de PHY (veja a Figura 9) , os bits de ID de serviço de utilidade pública permitem a distinção dos diferentes serviços de utilidade pública que usam este protocolo na mesma localização. Vantajosamente isso evita um serviço de utilidade pública entrar em uma célula pertencente a um de seus competidores. Quando a UID do pacote não combina com a UID definida no ponto final, o pacote recebido é descartado. Os dois bits subseqüentes do pacote preferencialmente são reservados, isto é, não usados inicialmente, para preservação de usos futuros, e preferencialmente deve ser regulado para 0.
Os bits de Length (comprimento) indicam o comprimento da MPDU, em bytes. Quando o número indicado de bytes é recebido, a camada física (se o resultado da decodificação de FEC for um pacote válido) indica a chegada de um quadro completo à camada de MAC, a qual verificará sua integridade (CRC). Então, a camada PHY, a qual por padrão está no modo de recepção, procura o próximo preâmbulo.
Para adicionar alguma robustez ao cabeçalho de PHY que não tem uma CRC, os campos UID, RSD e Length preferencialmente são complementados bit por bit, pelo presente assunto. Se os campos complementadores não combinarem com os campos associados, o pacote recebido será descartado.
Com referência ao Corpo de Quadro (veja a Figura 9), a unidade de dados de protocolo de MAC (MPDU) contém toda a informação requerida no nível de camada de MAC. O corpo de quadro também contém bytes redundantes adicionados de acordo com o algoritmo de FEC explicado aqui acima.
Na descrição aqui de cada camada no documento, uma interface e serviços com a camada superior são apresentados da mesma forma. Uma figura mostra as diferentes interações entre as camadas. Há três fluxos diferentes de informação entre eles, especificamente, requisições, confirmações e indicações. Estas comunicações internas diferentes então são explicadas.
Com referência a requisições, Layer-Name_Request-Name, elas são os serviços oferecidos por uma camada para a camada acima. Quando o serviço não é necessário pela camada imediatamente acima, mas pela uma, duas ou três vezes superior, as camadas intermediárias devem encaminhar o serviço. 0 usuário opcionalmente pode criar um atalho nas camadas médias, se desejado, para modalidades em particular.
Com referência a confirmações, Layer- Name_Confirmation-Name, elas são respostas às requisições. Toda requisição tem uma confirmação única pelo presente assunto. As confirmações nem sempre são enviadas imediatamente após uma requisição; ela depende do serviço.
A abordagem preferida é estabelecer um número para a requisição e, então, proporcionar o mesmo número quando a confirmação for enviada, de modo a se evitar um desentendimento. Note que o número associado à requisição não precisa estar correlacionado à ID dos quadros a enviar.
Com referência a Indicações, Layer-Name_Indication- Name, elas são enviadas por uma camada para a camada acima, elas não são uma resposta a uma requisição, usualmente elas reportam um evento. A camada que envia uma indicação não espera qualquer confirmação.
Ainda com respeito à criação de interfaces e serviços dentre camadas, a camada física está encarregada de enviar e receber pacotes de rádio no meio. Portanto, pelo presente assunto, por padrão, a camada física está no modo de recepção. Assim que um pacote é transmitido, a camada física comuta de volta para o modo de recepção. As mudanças de canal preferencialmente são requisitadas pela camada superior, a camada de MAC. A camada física também gerencia o transceptor concernente a sua interface de comunicação, calibração de canal, status de trava de PLL, leitura de RSSI e seleção de modo. No modo de transmissão (Tx) , ela computa uma FCS (com base no código de RS) e a adiciona ao pacote; ela então adiciona um cabeçalho físico (PHY-Header) e um preâmbulo. Finalmente, ela codifica e modula o pacote de rádio na taxa e na freqüência requeridas. No modo de recepção (Rx) , ela ouve o meio até encontrar um preâmbulo. Assim que reconhece o começo de delimitador de quadro no fim do preâmbulo, ela salva o tempo de recepção (SACT) e mede a intensidade de potência de entrada (RSSI). Então, ela demodula e decodifica o pacote de rádio. Após a remoção do preâmbulo e do cabeçalho, ela corrige o pacote, se necessário (e, se for possível) e indica para a camada de MAC a chegada de uma nova mensagem. A datação da mensagem deve ser acurada o bastante para permitir a operação apropriada do protocolo, conforme discutido de outra forma aqui com referência à camada de MAC.
A camada física propõe serviços diferentes, conforme representado pela Figura 10.
Em conjunto com as requisições de PHY, referenciadas como PHY_Request_Send, o objetivo é enviar um pacote pelo enlace de RF em um canal especificado e em um dado tempo. Os argumentos de entrada requisitados são: MPDU, Channel (canal) e Time (tempo) para envio do pacote. A operação pode ser descrita conforme se segue. A camada de MAC requisita a partir da camada PHY o envio de um pacote. 0 canal é proporcionado com a requisição. A camada PHY envia o pacote no tempo indicado pelo MAC. Uma informação de sincronismo pode ser proporcionada por várias formas alternativas pelo presente assunto, quanto a qual o usuário é livre para decidir. Assim que o pacote é transmitido, a camada física comuta de volta para o modo de recepção no canal padrão de intervalo de tempo e confirma para a camada de MAC o status da transmissão.
Em conjunto com as requisições de PHY para mudança de canal, referenciadas como PHY_Request_Change_Channel, o objetivo é mudar o canal de escuta. Os argumentos de entrada requisitados são Channel information (informação de canal). A operação pode ser descrita conforme se segue. A camada de MAC requisita a partir da camada PHY para mudar o canal de recepção padrão imediatamente.
Em conjunto com as requisições de PHY para leitura de um valor de RSSI, referenciado como PHY_Request_Read_RSSI, o objetivo é ler o valor de RSSI. Não há argumentos de entrada requisitados. A operação pode ser descrita conforme se segue. A requisição em questão pede à camada PHY para ler imediatamente o valor instantâneo de RSSI no canal atual.
Em conjunto com as requisições de PHY para começar ou parar, referenciadas como PHY_Request_Start_Stop_Rx, o objetivo é começar ou parar de ouvir o canal padrão atual.
Os argumentos de entrada requisitados são se é para Start (Começar) ou Stop (Parar) . Essa operação pode ser descrita conforme se segue. Esta requisição pede ã camada PHY para começar ou parar imediatamente de escutar o canal padrão atual. Preferencialmente, pelo presente assunto, a requisição de Stop é usada principalmente quando uma falta de potência é detectada, para se poupar energia.
Em conjunto com a confirmação de PHY, referenciada como PHY_Confirmation_Send, o objetivo é a Resposta de uma PHY_Request_Send. Os argumentos de saída requisitados são o byte de status (Status byte). A operação pode ser descrita como uma confirmação do status de uma mensagem transmitida. Ela pode ser Send_Ack, PLL_Unlock ou qualquer tipo de erros.
Em conjunto com a confirmação de mudança de PHY, referenciada como PHY_Confirmation_Change_Channel; o objetivo é a resposta de uma PHY_Request_Change_Channel. Os argumentos de saída requisitados são o byte de status (Status byte) . A operação pode ser descrita como uma confirmação do status da requisição de mudança de canal.
Ela pode ser Ack, PLL_Unlock ou qualquer tipo de erros.
Em conjunto com a confirmação de leitura de PHY, referenciada como PHY_Confirmation_Read_RSSI, o objetivo é a resposta de uma PHY_Request_Read_RSSI. Os argumentos de saída requisitados são o RSSI, A operação pode ser descrita como a camada PHY retornando o valor de RSSI atual. 0 valor é um caractere com sinal, expresso em dBm.
Em conjunto com a confirmação de PHY de começar ou parar a recepção, referenciada como PHY_Confirmation_Start_Stop_Rx, o objetivo é a resposta de uma PHY_Request_Start_Stop_Rx. Os argumentos de entrada requisitados são o byte de Status. A operação pode ser descrita como apenas confirmar se a requisição foi bem realizada.
Em conjunto com certas indicações de PHY, referenciadas como PHY_Indication_Received, o objetivo é indicar a recepção de um pacote entrando. Os argumentos de saída requisitados são MPDU, SACT, e RSSI. A operação pode ser descrita como após a recepção de uma mensagem, a camada PHY remover seu cabeçalho e proporcionar a MPDU para a camada de MAC. A camada de PHY também indica o RSSI medido durante a recepção e o valor de SACT (veja o capítulo de camada de MAC para a definição do SACT) guando o SFD tiver sido capturado.
A camada de enlace de dados é dividida em duas subcamadas, a camada de MAC e a camada de LLC. A camada de MAC tem várias tarefas, por meio das quais ela organiza uma transmissão de dados nos canais de RF e gerencia a sincronização.
Especificamente, com referência à Verificação de Redundância Cíclica (CRC), o primeiro papel da camada de MAC é detectar erros nos datagramas recebidos. Antes da transmissão, a camada de MAC computa uma CRC com base no pacote a ser transmitido e a adiciona no final do pacote. Devido a essa função, na recepção do pacote, a camada de MAC tem a capacidade de aceitar ou descartar mensagens, dependendo do valor dos códigos.
A segunda tarefa da camada de MAC é a montagem e a desmontagem do datagrama. A camada de MAC sabe que tipo de mensagem o medidor recebeu, quem a enviou (SA) e para quem ela é endereçada (DA) . Portanto, a camada de MAC também realiza reconhecimento. Quando uma mensagem é recebida, uma mensagem de reconhecimento é transmitida de volta no mesmo intervalo de tempo com um argumento de ACK ou de NACK, e com o número de quadro. Esta mensagem de reconhecimento não será adicionalmente reconhecida; a camada de MAC provê um reconhecimento em cada salto da mensagem, mas não há um eco de ponta a ponta de MAC.
Uma outra tarefa é o gerenciamento de vizinhança. Devido às mensagens recebidas e a seu cabeçalho, a camada de MAC gerencia uma tabela, onde várias indicações sobre os vizinhos a um salto são salvas. Quando um vizinho não transmitiu coisa alguma por um longo tempo, ele é considerado como tendo sido deixado e é removido da tabela. Esta tabela é usada para várias finalidades, como sincronização. Ela também é compartilhada com a camada de rede para se permitir um roteamento de mensagem.
Uma outra tarefa realizada pela camada de MAC é o gerenciamento de sincronização. A camada de MAC reajusta o começo de intervalos de tempo na escuta de um tráfego e no recebimento de pacotes de sincronização. Devido ao fato de conhecer a divisão de tempo e a seqüência de salto de freqüência, ela pode escolher o canal a usar. Para sincronização com outros pontos finais, isto é, se não houver tráfego, a camada de MAC envia sinais de orientação periódicos.
O que vem a seguir descreve os parâmetros da camada de MAC, mais especificamente, a escuta de uma variedade de parâmetros os quais são ajustáveis (isto é, passíveis de tweak). Ele provê uma descrição de cada parâmetro e alguns comentários sobre como modificar seu valor (efeito, limites...) e/ou suas relações com outros parâmetros.
Dependendo da localização e da banda na qual o presente assunto de protocolo opera, os valores padrões dos parâmetros de MAC mudam, conforme será entendido por aqueles de conhecimento comum na técnica, sem se requerer uma discussão detalhada adicional dos mesmos.
MAC_Beacon__Period_SYNC
Descrição: O período dos sinais de orientação enviados por um ponto final sincronizado, quando não tiver outras mensagens a enviar. Corresponde ao período máximo admitido de inatividade de rádio.
Comentários: O valor deste parâmetro depende da deriva de relógio e das margens de intervalo de tempo. Deve permitir que a rede fique sincronizada mesmo se vários sinais de orientação não forem ouvidos (isto é, deve ser menor do que MAC_Neighbor_Timeout). Quanto mais importante for a deriva de relógio, mais curto deverá ser o período de sinal de orientação. Os sinais de orientação não são enviados exatamente em cada período, mas são randomizados de modo a se evitarem colisões de sinal de orientação. MAC_CELL_Leaving_Process_Duration:
Descrição: 0 intervalo de tempo entre a recepção de um SYNC_ACK de uma outra célula (considerado melhor pelo ponto final) e o momento em que o ponto final realmente comuta a célula.
MAC_CELL_Switch_Hysteresis
Descrição: Este parâmetro define a histerese no processo de decisão para controle de transmissão adaptativo e célula. MA C_CELL_ Weight_CSI Descrição: No processo de comutação de célula, este parâmetro define o peso do tamanho de célula na seleção de célula.
MAC_ CELL_ Weíght_ GPD
Descrição: No processo de comutação de célula, este parâmetro define o peso do GPD na seleção de célula. MAC_ CELL_ Weight_Level
Descrição: No processo de comutação de célula, este parâmetro define o peso do nível na seleção de célula. MAC_Clock_Accuracy:
Descrição: Esta é a acurácia de cristal definida para incluir todos os parâmetros influenciadores (tolerância, temperatura e envelhecimento).
Comentário: Quanto melhor for a acurácia de cristal, mais facilmente a sincronização será mantida.
MAC_Discovery_Beacon_Period:
Descrição: O período entre dois sinais de orientação de descoberta durante a fase de descoberta.
Comentário: Este deve ser maior do que o tempo necessário para o envio de um sinal de orientação de descoberta. Ele também é dependente de quão rapidamente o firmware / hardware pode lidar com a transmissão de um sinal de orientação.
MAC_Excellent_Connectivity_Threshold:
Descrição: O número mínimo de pais de SYNC a partir do qual um nó é considerado como tendo um grau de conectividade excelente.
. MAC_FW_Accuracy:
Descrição: A acurácia do firmware para datação do envio / da recepção reais de uma mensagem.
Comentário: Isto depende da MCU e da freqüência.
MAC_ GPD_TD:
Descrição: Este parâmetro é usado para modelagem do atraso de propagação fixo através de cada nó da rede. Ele é usado para computação do GPD (atraso de propagação médio global).
Comentários: Aumentar o valor deste parâmetro fará com que o sistema proporcione uma vantagem para os percursos com menos saltos.
MAC_HFC_Max:
Descrição: Especifica a faixa do contador de hardware. MAC_HF_Length: Descrição: A extensão em intervalos de tempo de um hardware.
Um hiperquadro é uma sucessão de intervalos de tempo que segue a hiperseqüência de salto.
Comentário: Esta extensão é o produto do comprimento de superseqüência pelo número de canais.
HF_Length=Number__of_Channels* Hopping_Super_Sequence_Length MAC_Hopping_Super_Sequence_Length:
Descrição: 0 comprimento de uma superseqüência de salto de freqüência, também o número de seqüências de salto básicas usadas em uma hiperseqüência. MAC_Lístening_Window_Length:
Descrição: Comprimento da janela de escuta durante a fase de descoberta.
Comentários: Aumentar este comprimento diminuirá a probabilidade de colisão entre sinais de orientação forçados, mas desacelerará o processo de descoberta, se várias fases de descoberta forem necessárias para se encontrar um pai de SYNC.
MAC_LPD_Max:
Descrição: Valor máximo possível para o LPD (atraso de propagação local médio). MAC_LPD_NAVG:
Descrição: 0 comprimento de janela médio deslizante usado para a computação do LPD (atraso de propagação local médio).
Comentário: esta janela deve ser menor do que o valor de MAC_Neighbor_Timeout.
MAC_LPD_RSSI:
Descrição: Fator usado para inicialização do LPD (atraso de propagação local médio) a partir da leitura de RSSI.
MAC_LPD_Swítch :
Descrição: Fator usado para a inicialização de LPD (atraso de propagação local médio) a partir da leitura de RSSI.
MAC_Max_Discovery_Phase_Period:
Descrição: O período máximo entre duas fases de descoberta para um ponto final não sincronizado.
Comentário: Isto ê usado após as fases de descoberta mal sucedidas de MAC_Max_Nb_of_Discovery_Phases e deve ser muito maior do que MAC_Min_Discovery_Phase_Period.
MAC_Max_Nb_of_Discovery_Phases:
Descrição: 0 número máximo de fases de descoberta mal sucedidas antes do aumento do seu período.
Comentários: A razão para este parâmetro é acalmar os pontos finais órfãos. Deve ser regulado alto o bastante para tornar possível que um ponto final descubra várias células.
MAC_Max_Nb_of_Neighbors:
Descrição: O tamanho máximo da tabela de vizinho de MAC.
MAC__Max_Nb_of_SYNC_Request:
Descrição: O número máximo de vezes que um ponto final tenta enviar uma requisição de SYNC para cada pai de SYNC em potencial.
MAC_Max_Nb_of_Transmitted_Bytes__sTS:
Descrição: O número máximo de bytes que podem ser transmitidos durante um subintervalo de tempo. Isto inclui o pacote inteiro, isto é, MPDU, cabeçalho de PHY e preâmbulo.
Comentário: Este valor combinado com a taxa de dados afeta o comprimento de Sub_TS. MAC_Max_Nb_of_Transmitted_Bytes_TS:
Descrição: O número máximo de bytes que podem ser transmitidos durante um intervalo de tempo. Isto inclui o pacote inteiro, isto é, MPDUi cabeçalho de PHY e preâmbulo. Comentário: Este valor depende da taxa de dados, do comprimento de intervalo de tempo e das margens de intervalo de tempo.
MAC_Max_Packet_Length:
Descrição: 0 comprimento máximo de pacotes de PDU (expresso em bytes) que a camada de MAC autoriza a camada superior a enviar (o comprimento de LPDU).
Comentário:MAC_Max_Packet_Length MAC_Max_Nb_of_Transmitted_Bytes_TS -(Preâmbulo + PHY_header + FEC + MAC_Header + FCS).
MAC_Min_Discovery_Phase_Period:
Descrição: O período mínimo entre duas fases de descoberta para um ponto final não sincronizado.
Comentário: Este deve ser maior do que o tempo necessário para o envio dos sinais de orientação de descoberta mais MAC_Listening_Window_Length.
MA C_Nb_of_Basic_Hoρρing_Sequences:
Descrição: O número de seqüências de salto de freqüência básicas que um ponto final pode gerar. Cada seqüência de salto é uma sucessão de todos os canais pré-def inidos. Cada um dos canais MAC_Number_of_Channels aparece uma vez e apenas uma vez nesta sucessão.
Comentário: Este valor deve ser maior do que MAC_ Hopping_Super_Sequence_Length. MAC_Nb_of_Sub_ TS: Descrição: 0 número de subintervalos de tempo em um intervalo de tempo. O começo de um Sub-TS marca o começo potencial da transmissão de um pacote.
Comentários: 0 número de Sub-TS é ((TS_Length-2* TS_Margin) /Sub_TS_Length) . É assumido que os valores de comprimento são escolhidos para se tornar este um inteiro. MAC_Max_nb_of_downlink_buffered_packets:
Descrição: 0 número máximo de pacotes que um ponto final pode salvar em sua memória. Ele concerne apenas aos pacotes indo do mestre de célula para os pontos finais (enlace descendente).
MAC_Max_nb_of_uplink_buffered_packets:
Descrição: O número máximo de pacotes que um ponto final pode salvar em sua memória. Ele concerne apenas aos pacotes indo dos pontos finais para o mestre de célula (enlace ascendente).
MAC_Neighbor_Timeout:
Descrição: O limite de tempo para a camada de MAC decidir que um ponto final não é um vizinho mais porque a última recepção ocorreu mais do que após o MAC_Neighbor_Timeout.
Comentários: Isto depende da deriva de relógio e das margens de intervalo de tempo. Um ponto final não deve ser considerado um vizinho se houver uma chance de ele não estar mais sincronizado. MAC__Number_of_Channels:
Descrição: O número de canais usados nas seqüências de salto de freqüência básicas.
Comentários: O valor mínimo para este parâmetro é fixado pelos regulamentos de espectro de dispersão: 15, 20, 25 ou 50 canais, dependendo dos países e dos recursos inteligentes de salto de freqüência. MAC_RSSI_Sampling_Rate:
Descrição: Freqüência de leituras de RSSI durante a análise ambiental para a computação de RSSI médio e da função de autocorrelação de RSSI.
MA C_RXI_Decay:
Descrição: Esta constante é usada para computação do indicador de taxa de recepção (RXI). O RXI é periodicamente multiplicado por esta constante para se fazer com que o indicador decaia no tempo quando nenhuma mensagem for recebida.
MAC_RXI_Increment:
Descrição: Esta constante é usada para computação do indicador de taxa de recepção (RXI). Mediante o recebimento de uma mensagem a partir de um vizinho, seu RXI é incrementado por esta constante.
MAC_RXI_Threshold:
Descrição: Os valores de RXI acima deste limite são considerados como sendo uma indicação de um enlace confiável. Isto é usado na computação de números de mérito para a escolha de pais de sincronização.
MAC_SACT_Resolution:
Descrição: O valor do bit menos significativo do temporizador de SACT, quando o valor deste temporizador for trocado entre os pontos finais.
Comentário: O temporizador de SACT pode ser localmente implementado com uma resolução mais alta dada pelo parâmetro MAC_FW_Accuracy.
MAC_Sub_TS_Length:
Descrição: O comprimento de um Sub_TS. Ele corresponde ao comprimento máximo da maior mensagem de MAC (preâmbulo + cabeçalho de PHY + FEC + cabeçalho de MAC + FCS) . Comentário: Deve ser arredondado para a obtenção de um número inteiro de Sub_TS por TS. MAC_SYNC_Disc_Weigh t_CSI
Descrição: Na fase de descoberta, este parâmetro define o peso do CSI de vizinhos no processo de seleção de pai de sincronização. MAC_SYNC_Disc_Wei gh t_GPD
Descrição: Na fase de descoberta, este parâmetro define o peso do GPD de vizinhos no processo de seleção de pai de sincronização.
MAC_SYNC_Disc_Weight _Level
Descrição: Na fase de descoberta, este parâmetro define o peso do nível de vizinhos no processo de seleção de pai de sincronização.
MA C_ SYNC_Father_Request_Beacon_Threshold:
Descrição: Duração usada para se determinar se um ponto final ainda está em sincronização com um pai, antes da aceitação que um outro ponto final fique sincronizado com ele. Se uma mensagem a partir de um pai saudável tiver sido recebida neste tempo, não haverá necessidade de requisitar um sinal de orientação a partir dele antes de responder a uma requisição de SYNC.
Comentário: Este valor deve ser menor do que MAC_Beacon_Period_SYNC.
MAC_SYNC_Request_Period:
Descrição: O período mínimo entre duas requisições diferentes de SYNC enviadas para o mesmo pai de SYNC em potencial. MAC_Traffic_Density_max
Descrição: Qualquer ponto final na malha ajustará sua janela de randomização de transmissão de modo a se evitar a criação de uma densidade de entrada de tráfego acima daquele limite para cada um de seus pais.
Comentários: 0 valor deste parâmetro deve sempre ser menor do que um. Os valores próximos de um podem melhorar o ritmo de transferência máximo do sistema, mas aumentam o risco de emperramento do tráfego de dados com colisões. MAC_Traffic_Monitoring_Window
Descrição: 0 comprimento da janela média deslizante usada por um ponto final para a monitoração do tráfego de vizinhos. Este comprimento é expresso em unidades de intervalos de tempo.
MAC_TS_Length:
Descrição: 0 comprimento de um intervalo de tempo. Durante o intervalo de tempo inteiro, o mesmo canal será regulado, exceto para o envio de sinais de orientação forçados. Comentários: 0 valor máximo de TS_Length pode ser fixado por regulamentos de espectro de dispersão em alguns países, (por exemplo, 400 ms para o PHY-FHSS-NA- 915) . 0 comprimento padrão corresponde a ({Max_Nb_of_Transmitted_Bytes_TS * 8) / Bit_Rate) + 2 * TSJMargin. MA C_ TS_Ma rgi η:
Descrição: A duração de cada intervalo de tempo nas extremidades de um intervalo de tempo quando um ponto final não tiver permissão para transmitir. Quando no modo de recepção, o ponto final deve estar ouvindo através do intervalo de tempo inteiro, de modo a se ser capaz de completar a recepção de uma mensagem vindo de um vizinho com intervalos de tempo ligeiramente desalinhados. Comentário: 0 valor de TS_Margin depende da pior deriva de relógio entre dois pontos finais e entre duas mensagens recebidas. Margens mais largas permitirão mais deriva de cristal ou mais tempo entre as mensagens, mas diminuirão o número máximo de bytes transmitidos por TS e, assim, o ritmo de transferência do sistema.
MAC_Tx_Window_max:
Descrição: O valor máximo para a janela de randomização usada por um ponto final para a transmissão de seus pacotes de dados.
Comentários: Apenas um pacote deve ser normalmente transmitido em uma janela de randomização e a posição do pacote nesta janela é randômica. O protocolo não proíbe que pacotes curtos sejam transmitidos na mesma janela, mas isto também deve seguir as regras de prioridade. MAC_jTx_Window_rnin:
Descrição: O valor mínimo para a janela de randomização usada por um ponto final para a transmissão de seus pacotes de dados.
MAC_Unsynchronízed_Timeout:
Descrição: Duração após a qual um ponto final ainda na fase de descoberta reinicializará sua noção de célula proibida (e o número de fases de descoberta que ele já tentou). MAC_Warm_Start_Discovery_Duration:
Descrição: número de fases de descoberta durante a qual um ponto final com uma célula preferida tenta se sincronizar com ela.
Comentários: Este valor deve ser grande o bastante para garantir uma alta probabilidade de se encontrar a mesma célula após uma falta, mas pequeno o bastante para não atrasar a possível sincronização com uma outra célula, se a preferida não estiver mais disponível. Isto não afeta a noção de célula proibida.
MAC_Xdrift_Filter_A, MAC_Xdrift_Fi1ter_B:
Descrição: Estes são os coeficientes de filtro para uma correção de deriva de cristal.
Comentários: A modificação destes coeficientes tornará a resposta de degrau de filtração mais lenta ou mais rápida. Uma resposta de degrau mais rápida pode ser desejável para a aceleração da sincronização de freqüência dos nós. Qualquer modificação destes parâmetros deve ser feita cuidadosamente para se evitar tornar o sistema instável, veja o apêndice relevante.
MAC_Xdrift_LeapTS
Descrição: Este é o intervalo entre os intervalos de tempo de pulo. A cada MAC^Xdrift_LeapTS intervalos de tempo, o SACT é carregado com seu valor inicial mais uma pequena correção para compensação da deriva do cristal.
Comentários: Valores grandes deste parâmetro aumentarão a resolução da compensação de deriva de cristal, mas também aumentarão a importância da correção a ser aplicada a cada intervalo de tempo de pulo. Valores grandes de MAC Xdrift_LeapTS devem ser usados apenas com bons cristais, de modo a se evitar uma saída de sincronização entre dois intervalos de tempo de pulo.
MAC_Xdrift_Tmin:
Descrição: Este é o intervalo de tempo mínimo pelo qual as correções de relógio precisam ser somadas, antes de um novo valor de correção de deriva de cristal poder ser computado. Comentários: O valor deste parâmetro depende do erro médio feito quando o relógio (SACT) é ajustado a partir de pacotes entrando. Se incertezas no tempo de chegada de pacotes forem importantes, este parâmetro deve ser aumentado para se calcularem as médias das incertezas.
Dependendo dos regulamentos locais e da banda de freqüência na qual o protocolo opera, os valores padrões dos parâmetros de MAC mudam. A tabela a seguir proporciona valores padrões para os parâmetros relacionados à operação geral ou interna da camada de MAC, bem como o gerenciamento de carga de tráfego. <table>table see original document page 133</column></row><table> <table>table see original document page 134</column></row><table>
A Tabela a seguir proporciona os valores padronizados para os parâmetros relacionados à fase de descoberta._
<table>table see original document page 134</column></row><table>
A próxima tabela proporciona os valores padronizados para os parâmetros relacionados à sincronização, escolha de pai de sincronização, escolha de célula e gerenciamento de tabela de vizinho. <table>table see original document page 135</column></row><table> <table>table see original document page 136</column></row><table>
O que vem a seguir discute geralmente as facetas de divisão de freqüência e de tempo do presente assunto. Em particular, o presente assunto de protocolo é baseado em um sistema de salto de freqüência para melhor imunidade à interferência e para estar de acordo com os regulamentos de espectro de dispersão em alguns países. Na América do Norte, um sistema de salto de freqüência permite uma potência transmitida mais alta do que um sistema usando um único canal estreito. Isto significa que freqüência e tempo serão divididos. Para o estabelecimento de um enlace de RF entre dois nós, duas condições têm que ser respeitadas, as quais são que duas entidades têm que operar na mesma freqüência e ao mesmo tempo. O protocolo respeita estas duas condições pela adoção de um esquema de intervalo de tempo.
O quadro de tempo é dividido pelo presente assunto em intervalos de tempo regulares, cada um deles operando em uma freqüência diferente. Nos Estados Unidos, as regras da FCC (Parte 15.247) especificam que para um sistema de FHSS, o tempo médio de ocupação de qualquer freqüência não deve ser maior do que 0,4 s em uma janela de 20 segundos. Na Europa, a mesma limitação se aplica na banda de 2,4 GHz.
Por outro lado, não há uma limitação de tempo de espera por canal na banda de 868 MHz. Dispositivos operando na banda de 868 MHz devem estar em conformidade com um limite de ciclo de carga geral que tem a média calculada por todos os canais usados pelo sistema. Para o presente assunto, a duração de intervalo de tempo foi dimensionada para conter uma única mensagem de tamanho máximo, conforme representado pela Figura 11.
Os regulamentos de FHSS aplicáveis também especificam o número mínimo de freqüências que têm que ser usadas. Na América do Norte, na banda de 915 MHz, se os canais forem de menos de 25 0 kHz de largura, o número mínimo de canais será de 50. Para a banda de 2,4 GHz, na América do Norte, bem como na Europa, pelo menos 15 canais são requeridos. Há uma exceção a essas regras. Em particular, na banda européia de 2,4 GHz, pelo menos 20 canais são requeridos, se uma estratégia de salto de freqüência adaptativo for usada. O salto de freqüência adaptativo permite a seleção dos melhores canais, para se evitar uma interferência. Por outro lado, não há um número mínimo de canais na banda européia de 868 MHz. Quanto mais canais houver no sistema, mais alto o isolamento entre células adjacentes será, mas mais longo será o tempo de sincronização.
De modo a se tornar possível uma comunicação por RF, quaisquer dois nós da rede precisam conhecer precisamente qual canal usar em todo intervalo de tempo. Para se tornar essa operação possível, o uso de canal é organizado de acordo com uma seqüência de salto de freqüência conhecida por todos os pontos finais pertencentes à rede. Essa seqüência é projetada para uso de todos os canais igualmente na média.
Para a provisão de isolamento entre células adjacentes, cada célula tem sua própria seqüência de salto de freqüência. Essa seqüência pelo presente assunto é descoberta por todos os pontos finais da célula durante o processo de sincronização. Para a adição de mais isolamento entre as células, foi escolhido pelo presente assunto organizar o padrão de salto em hiperquadros. Veja também a presente Figura 12 que representa o presente assunto de hardware e seqüência de canal, com base em 15 canais de exemplo, com 10 seqüências básicas. Uma técnica de hiperquadro como essa segue uma hiperseqüência de salto de freqüência construída com várias seqüências de salto de freqüência básicas diferentes, o que torna uma seqüência mais longa, mas sempre com o mesmo subconjunto de canais. A seqüência agora é constituída com K diferentes seqüências básicas, o que significa MAC HF_Length=K*MAC_Number_of_Channels intervalos de tempo.
Essa presente abordagem também adiciona uma melhor imunidade a bloqueadores. Em uma dada célula, todos os hiperquadros preferencialmente são idênticos pelo presente assunto. Uma vez que o sistema tenha passado através de um hiperquadro, ele repete a mesma seqüência de uma forma periódica.
Com respeito à presente atribuição de seqüência de canal, pelo presente assunto, todos os pontos finais conhecem as seqüências de canal diferentes que podem ser usadas, mas apenas uma seqüência de canal é usada por célula. A seqüência de canal é dada pelo arranjo de célula.
A seqüência é computada pelo conhecimento do algoritmo especifico, o qual usa o endereço de C12.22 do relê de célula como uma semente. Para mudança da seqüência de salto em uma célula, o agente de coleta tem que mudar o endereço do relê de célula.
Se houver vários relês de célula na mesma área, é imperativo que eles sigam seqüências de canal diferentes. Apenas um relê de célula é possível por célula (porque os relês de célula não são sincronizados uns com os outros). Ao contrário, pelo presente assunto, um número alto de células diferentes pode operar na mesma área, porque eles não ouvem cada outro na maior parte do tempo.
O número de célula dado para o relê de célula é transmitido e encaminhado para todos os pontos finais na célula, pelo presente assunto. Esse campo é usado para a geração da seqüência de salto, conforme descrito de outra forma aqui.
Um isolamento de célula é obtido pelo presente assunto preferencialmente através de seqüências quase ortogonais em uma rede de salto de freqüência. Mais particularmente, de acordo com o presente assunto, duas seqüências pseudo- randômicas embutidas são utilizadas para isolamento de células em uma rede de espectro de dispersão de salto de freqüência. A seqüência interna é gerada com uma aritmética de campo de Galois e a seqüência externa é uma seqüência de Fibonacci que usa o endereço de célula única como uma semente.
O presente assunto de protocolo é baseado em um espectro de dispersão de salto de freqüência (FHSS) para melhor imunidade à interferência e conformidade com regulamentos de rádio em alguns países. Em um sistema de FHSS típico, todos os nós saltam sua freqüência de canal de acordo com a mesma seqüência pseudo-randômica, de modo a estarem perfeitamente sincronizados para recepção e transmissão. 0 padrão de salto de freqüência é a regra que atribui um número de canal a cada intervalo de tempo do protocolo Aloha com intervalo. Esse padrão é periódico, e se repetirá indefinidamente.
Como é muito difícil manter uma boa sincronização por um número muito grande de nós, o sistema do presente assunto é vantajosamente dividido em células. Cada célula contém um número limitado de nós e tem sua própria seqüência pseudo-randômica para sincronização de transceptor. Pelo presente assunto, todos os nós dentro de uma célula são sincronizados com cada outro, mas as células diferentes não são sincronizadas umas com as outras. Problemas técnicos dessa abordagem são considerados pelo presente assunto, incluindo como encontrar uma forma simples de gerar uma seqüência pseudo-randômica para cada célula, e como garantir que estas seqüências sejam únicas e provejam um isolamento suficiente entre células adjacentes.
O presente assunto combina o uso de uma aritmética de campo de Galois e seqüências de Fibonacci para a geração de seqüências pseudo-randômicas. A seqüência resultante é a combinação de duas seqüências embutidas. A interna é gerada pela aritmética de campo de Galois e a externa é gerada por uma seqüência de Fibonacci usando o endereço de célula como semente. O endereço de célula é único para cada célula e levará a seqüências completamente diferentes para quaisquer duas células adjacentes, mesmo se os endereços diferirem apenas em um.
O que vem a seguir é uma descrição formal do presente assunto de construção de padrão de salto.
A seqüência de salto interna é construída com um campo de Galois de ordem p, onde pé um número primo. Uma adição ou multiplicação neste campo é para ser realizada em módulo de p. Este campo de Galois é:
<formula>formula see original document page 141</formula>
Em qualquer campo de Galois, podem-se encontrar elementos primitivos. Um elemento é dito como sendo primitivo se suas potências sucessivas gerarem todos os elementos não nulos do campo. Se α for um elemento primitivo do campo, o campo poderá ser escrito conforme se segue:
Para a criação da seqüência de salto interna a partir disto, apenas os elementos não nulos do campo são selecionados e uma definição conforme se segue é estabelecida da tupla (p-1) ordenada (1, a, a2, a3, ..., ap 2) 0 comprimento da seqüência de salto interna (o número de saltos na seqüência) é igual ao número de canais usados pelo sistema, N = p-1. 0 enlace de RF usará várias seqüências de salto internas diferentes. Cada uma dessas seqüências será gerada por seu próprio elemento primitivo. Diferentes elementos primitivos são selecionados para a geração de K diferentes seqüências de salto internas. Esses elementos primitivos são (α0, αχ, α2,..., ακ-1) .
As seqüências de salto internas são numeradas de 0 a K-1. A k-ésima seqüência de salto é gerada pelo k-ésimo elemento primitivo e sua expressão é:
<formula>formula see original document page 142</formula>
Ou, em uma forma compacta:
<formula>formula see original document page 142</formula>
Onde IHS(k,n) é o número de canal no enésimo salto da k-ésima seqüência de salto interna e ak é o elemento primitivo da k-ésima seqüência de salto interna.
A seqüência de salto externa é pretendida para o presente assunto para a provisão de um padrão de salto o qual é único para cada célula. Para a feitura do padrão único, a seqüência de salto externa é construída com uma seqüência de Fibonacci usando o identificador de célula (Cell Identificator) como uma semente, conforme se segue:
OHS(O) = CeII Identifier(O)
OHS(1) = Cell Identifier(1)
OHS(n) = OHS (n -1) + OHS (n - 2), η = 2,3,4,.....,M-1
Aqui, o identificador de célula é dividido em duas partes: a mais significativa e a menos significativa. O inteiro M é o comprimento da seqüência externa. Como uma presente alternativa, qualquer extensão deste processo é possível pelo presente assunto. Por exemplo, pode-se dividir o identificador de célula em quatro partes e usar uma seqüência de Tetranacci, conforme se segue: <formula>formula see original document page 143</formula>
Os elementos da seqüência externa são usados para a seleção de uma seqüência de salto de freqüência interna de N saltos específica. Para essa finalidade, os elementos da seqüência de Fibonacci são computados com um módulo aritmético, de modo a se mapear no conjunto de seqüências de salto disponíveis. A partir da seqüência interna e da seqüência externa, a hiperseqüência de salto resultante é obtida com o procedimento de embutimento a seguir:
<formula>formula see original document page 143</formula>
Como a computação de potências mais altas de um elemento primitivo pode ser difícil de implementar em um microprocessador, é recomendado pelo presente assunto computar a seqüência de salto interna iterativamente. Com o primeiro salto sempre designado como 1, cada salto sucessivo pode ser facilmente computado a partir do salto precedente pela equação a seguir.
<formula>formula see original document page 143</formula>
Esta seqüência de salto interna é muito prontamente computada com apenas o conhecimento do salto prévio e do número de seqüência de salto. Isto é pretendido pelo presente assunto para ser computado antes de cada salto, evitando-se a necessidade de armazenamento de todas as seqüências de salto possíveis na memória.
O uso de suas seqüências embutidas pelo presente assunto vantajosamente melhora a dispersão e a imunidade a uma interferência. Também, uma forma simples e iterativa de computação das seqüências de salto é provida, uma forma simples para isolamento das células é provida, e a implementação iterativa leva a exigências muito baixas de memória e de carga de computação.
A superseqüência de salto do presente assunto é pretendida para a provisão de um padrão de salto o qual é único para cada célula. Para a feitura do padrão único, a superseqüência de salto é construída com uma seqüência de Fibonacci usando-se o identificador de camada de eletrodo CELL como uma semente. CELL é um endereço de 2 bytes. Isso é primeiramente dividido em quatro números de 4 bits, conforme se segue:
<formula>formula see original document page 144</formula>
A seqüência de Fibonacci então é construída com o seguinte:
<formula>formula see original document page 144</formula>
Nessa soma, todas as adições devem ser realizadas em módulo 16. Cada termo na seqüência então é um inteiro entre 0 e 15, conforme se segue: 0 ≤ Cid ≤ 15
O inteiro M é o comprimento da superseqüência. Alguém de conhecimento comum na técnica observará que esta indicação em particular não é uma seqüência de Fibonacci de bona fíde, porque quatro termos são usados na soma, ao invés de dois. Alguns autores cunharam o termo Tetranacci para denominar essa seqüência. A superseqüência de salto será:
HSS = (Cid(4),Cid(5),...,Cid(M+ 3))
Isto também pode ser escrito como:
HSS (V) = Cid (n+4)+ 4), 0 ≤ n ≤ M -1
Os elementos da superseqüência são usados para a seleção de uma seqüência de salto de freqüência básica de N saltos especifica. Se K = 16, cada elemento da seqüência de Fibonacci naturalmente aponta para uma seqüência de salto. Este é o caso para a camada física de PHY-FHSS-NA - 915 . Se menos de 16 seqüências de salto básicas estiverem disponíveis, os elementos de seqüência de Fibonacci serão convertidos em módulo K inteiros de modo a se mapear no conjunto de seqüências de salto disponíveis, conforme se segue:
<table>table see original document page 145</column></row><table>
Dada a superseqüência de salto:
HSS = (HSS{0), HSS{ 1),... HSS (M -1))
E o conjunto de K seqüências de salto básicas: <formula>formula see original document page 146</formula>
A hiperseqüência é construída da forma a seguir:
([HS(HSSiO)tO), HS(HSSiO), 1),.., HS (HSS(O)3 N -1)], [HS(HSSi 1),0),HS(HSSil),(1),...,HS(HSS(1),N -1)],
[HS(HSS(M -1),0 ),HS(HSS(M - ]), 1 ),...,HS (HSS(M -1),N-1)]}
Esta hiperseqüência de M * N saltos se repete indefinidamente de uma forma periódica. Durante o primeiro intervalo de tempo, o transceptor de ponto final usará a freqüência indicada pelo primeiro elemento desta hiperseqüência para ambas as atividades de transmissão e de recepção. Para o segundo intervalo de tempo, usará o segundo elemento e assim por diante.
O comprimento da hiperseqüência, M*N, está relacionado ao parâmetro de camada de MAC:
M*N = MAC_HF_Length
Um caso especial vale ã pena mencionar. Se o identificador de célula estiver vazio, isto é, se ele contiver apenas zeros, a superseqüência será uma seqüência constante de zeros. Neste caso, a hiperseqüência se reduz para a repetição da primeira seqüência de salto básica conforme se segue:
[HS (0,0), HS(0,]),..., HS (0,N - 1)]
A sucessão de M*N intervalos de tempo usando os canais proporcionados por esta hiperseqüência é denominada um hiperquadro. A presente Figura 13 ilustra uma presente estrutura de exemplo de um hiperquadro. 0 índice de seqüência de salto básica é o número de salto em cada seqüência de salto básica e o índice de superseqüência especifica a posição na superseqüência.
A hiperseqüência do presente assunto foi projetada para se evitar ter duas células diferentes trabalhando com o mesmo padrão de salto, desde que tenham identificadores de célula diferentes, conforme definido aqui. Como é provável que duas células adjacentes tenham identificadores de célula próximos, foi verificado se o algoritmo proposto leva a dois padrões de salto muito diferentes, mesmo se os identificadores de célula diferirem apenas por um bit.
Estas seqüências, não obstante, não são totalmente ortogonais e algumas colisões são inevitáveis. Deve-se ter em mente que os relógios de células adjacentes derivarão com respeito a cada outro. A conseqüência é que duas superseqüências que diferem apenas por uma permutação cíclica não necessariamente proverão um isolamento de célula de uma forma confiável. A probabilidade de isto acontecer, contudo, acredita-se que seja baixa.
Para a camada física da modalidade de exemplo de PHY- FHSS-NA-915 (com referência a 915 MHz) , o número de canais é:
N = MAC_Number_of_Channels = 5 2
0 número de seqüências de salto básicas é K = 16, o comprimento de superseqüência é M = 16 e o comprimento de hiperseqüência é:
M*N = MAC_HF_Length = 52 χ 16 = 832
A presente Figura 14 proporciona os elementos primitivos para as K seqüências de salto básicas para uma modalidade de exemplo de PHY-FHSS-NA-915.
A regra de geração de seqüência de salto básica é, para cada uma das 16 seqüências:
<formula>formula see original document page 148</formula>
Como um exemplo, isto é o detalhe para a geração do número de seqüência de salto básica 2. A partir da tabela da Figura 14, o elemento primitivo para o número de seqüência de salto básica 2 é 5. A seqüência será computada por:
<formula>formula see original document page 148</formula>
O primeiro salto sempre é:
HS(2,0) = 1(número de canal 1 será usado)
O segundo salto é:
HS (2,1) = modulo (5*1; 53) = 5 (número de canal 5 usado como exemplo)
O terceiro salto é: HS (2,2) = modulo(5*5; 53) = 25 (número de canal 25 usado como exemplo)
O quarto salto é: HS (2,3) = modulo(5*25 ; 53 ) = modulo(125;53) = 125 - 2*53 =
O quinto salto é: HS (2,4) = modulo(5*19;53) = modulo(95;53) = 95 - 53 = 42
O sexto salto é: HS (2,5) = modulo(5*42 ; 53) = modulo(210;53) = 210 - 3*53 = Esse processo continua até os 52 saltos serem computados.
Com referência à condução de comunicações com uma célula adjacente, se a seqüência de salto deve ser implementada por um módulo η multiplicação ou por uma tabela de consulta é uma questão de transigência entre velocidade de computação e memória. Embora a abordagem iterativa tenha sido sugerida acima, qualquer escolha pode ser feita pelo usuário, de acordo com o presente assunto, sem se afetarem adversamente os aspectos mais amplos do presente protocolo em questão.
Há uma situação em que as condições dessa transigência são diferentes. Quando um ponto final que se comunicar com um outro ponto final pertencente a uma célula diferente, há uma necessidade de ele ser capaz de rapidamente computar o padrão de salto da nova célula, de modo a se ser capaz de interromper com a freqüência direita no meio do padrão de salto. Se o processo de multiplicação iterativo for usado nesse caso, ele levará a um número de módulo ρ multiplicações tão grande quanto o número na seqüência básica. Se isto for em uma dada instância um encargo excessivo para o microprocessador, o presente assunto alternativamente poderá usar um algoritmo de exponenciação por elevação ao quadrado para aceleração da computação. Esse algoritmo, adaptado para computações criptográficas, pode ser aplicado de forma iterativa e levará a um número de operações proporcional ao algoritmo na base dois do número de salto. O ganho no tempo de computação, portanto, é relativamente grande.
O algoritmo de exponenciação por elevação ao quadrado consiste na aplicação iterativa da equação a seguir:
<formula>formula see original document page 150</formula>
este algoritmo será usado para a computação da freqüência de canal começando a partir da expressão a seguir da seqüência de salto:
<formula>formula see original document page 150</formula>
O exemplo a seguir é com base na computação do número de canal para o número de salto 33 do número de seqüência básico 7 da camada física de PHY-FHSS-NA-915 .
A partir da tabela referenciada acima (Figura 14) , o número de seqüência de salto básica 7 usa o elemento primitivo 19. Portanto, é computado:
Agora, realizando-se a primeira elevação ao quadrado:
<formula>formula see original document page 150</formula>
e na etapa seguinte: Segunda elevação: 432 =1849 = 47 (mod53)
HS(7,33) - 19(47)8 = 19(472)4 (mod 53)
Terceira elevação: 47^2 = 2209 = 36 (mod 53)
HS(7,33) = 19(36)4 19(362) (mod 53)
Quarta elevação: 36^=1296 = 24 (mod53)
HS(7,33) = 19(24)2 (mod 53)
Quinta elevação: 242 = 576 = 46 (mod 53)
E uma multiplicação final:
HSp,33) = 19χ46 = 874 - 26 (mod 53)
Embora o número de canal seja 26, a computação de exemplo em questão foi computada em apenas 6 operações, ao invés de em 32.
Com referência às posições de mensagem e subintervalos de tempo, as mensagens terão comprimentos muito diferentes. Em uma extremidade, seriam encontradas mensagens de MAC, tais como sinais de orientação, as quais ocupam uma percentagem pequena da duração de intervalo de tempo, e, na outra extremidade, seriam encontradas mensagens de camadas acima, as quais ocupam um intervalo de tempo completo.
O comprimento de TS foi dimensionado para conter uma mensagem do tamanho máximo,
MAC_Max_Nb _of_Transmitted_Bytes. Se a camada de API requisitar uma mensagem mais longa, o LLC fragmentará esta mensagem em pacotes. Obviamente, cada pacote não excederá a MAC Max Nb of Transmitted_Bytes (cabeçalho de PHY e preâmbulo incluídos) , conforme também referenciado de outra forma em conjunto com a descrição da camada de LLC.
As mensagens de MAC são as mensagens mais curtas que podem ser enviadas. Uma vez que a camada física por padrão está no modo de recepção, os pacotes podem ser recebidos em um intervalo de tempo em que um pacote foi enviado. Para limitação do número de colisões dentro de um TS entre os pacotes recebidos e transmitidos, os intervalos de tempo são divididos em subintervalos de tempo (Sub_TS) de tamanhos iguais (MAC_Sub_TS_Length). Seu tamanho é regulado para se adaptar na mais longa das mensagens de MAC. Por exemplo, na Figura 15 (que mostra as margens de TS e Subintervalos de tempo), até 6 sinais de orientação a partir de vizinhos diferentes podem ser recebidos em um único TS.
0 tamanho máximo de uma mensagem que pode se adaptar em um subintervalo de tempo é Max_Nb_of_Transmitted_Bytes_sTS. Se uma mensagem for longa demais para se adaptar em um subintervalo de tempo, ela usará vários, mas sempre começará no começo de um subintervalo de tempo, de modo a ocupar um número mínimo deles. Este realmente é o conceito de acesso Aloha com intervalo, o qual é aplicado aqui a uma estrutura de subintervalo de tempo de um intervalo de tempo.
Quando uma mensagem deve ser enviada, a seleção do número Sub_TS é randomizada entre o segundo e o último TS, uma parte disso sendo livre de transmissões. Se transmissões não forem permitidas nesta parte do TS, as recepções o serão.
Estas margens proporcionarão a possibilidade de comunicação entre dois pontos finais que não sejam perfeitamente sincronizados. 0 comprimento destas margens, MAC_TS_Margin, reflete o erro autorizado máximo de sincronização no tempo entre duas ressincronizações, no cenário de pior caso (erros máximos de relógio, vários sinais de orientação perdidos, nenhum tráfego, etc.) .
A rede pelo presente assunto é dividida em células, onde se espera que o tráfego seja baixo. Mais ainda, a rede opera em uma banda de ISM, em que muitos outros usuários ocupam o mesmo meio (com as mesmas regras) . Assim, a probabilidade de colisão devido ao ambiente externo tende a ser mais alta do que a probabilidade de colisão na rede em questão em si. É por isso que o algoritmo de Aloha com intervalo é apropriado para o gerenciamento do acesso ao meio. A célula inteira é sincronizada no tempo e na freqüência (conforme descrito aqui). Quando um ponto final quer falar, ele apenas empurra sua mensagem para o meio em um intervalo de tempo randômico. O destinatário receberá a mensagem porque ela é sincronizada e porque, por padrão, um ponto final está ouvindo o meio (a camada física, por padrão, está no modo de recepção). Obviamente, uma colisão ocorre quando dois pontos finais próximos querem falar no mesmo intervalo de tempo, mas isto é resolvido por uma repetição das mensagens, uma repetição gerenciada pela camada de LLC. Quando se empurram dados no meio, a camada de MAC não se importa se é uma mensagem de enlace ascendente ou de enlace descendente; a taxa de bit e todos os outros parâmetros são os mesmos para ambas as formas. Uma transmissão de dados não é hierárquica e simétrica.
Devido ao fato de canais serem igualmente representados e devido ao fato de dados poderem ser empurrados para qualquer intervalo de tempo, o presente assunto de protocolo respeita a ocupação uniforme do meio pela banda.
É muito importante que o tráfego permaneça muito baixo, para se garantir um bom funcionamento do acesso de Aloha com intervalo. O Aloha com intervalo permitirá até 25% de carga de dados, se a rede em questão estivesse sozinha no meio. Em uma situação de vida real, 3% de carga de dados são mais adequados.
A cada vez em que um pacote é recebido a partir de um vizinho, a camada física torna disponível uma leitura de RSSI para aquele pacote. Para cada vizinho em sua tabela de vizinho, a camada de MAC computará um valor médio deste RSSI com um filtro de Kalman. Este filtro proporcionará uma estimativa acurada do RSSI médio tão logo umas poucas leituras de RSSI estejam disponíveis. O pseudocódigo a seguir proporciona os detalhes deste algoritmo:
Mediante a recepção de um pacote a partir do vizinho X Se este for o primeiro pacote recebido a partir de X, então,
RSSI_Average = leitura de RSSI atual para aquele pacote
RSSI_Cov = 255
Else (Caso contrário) computar o novo RSSI__Average com
<formula>formula see original document page 154</formula>
Novo RSSI_Average = (1-KG)(Antigo RSSI_Average) + KG(leitura de RSSI atual) Novo RSSI_Cov = (1-KG)(Antigo RSSI_Cov)
End if (fim do se)
Atualizar a tabela de vizinho com o novo valor de RSSI_Average e o novo valor de RSSI_Cov.
RSSI_Cov é a estimativa da covariância do RSSI, tem que ser mantida na memória para cada vizinho, bem como o RSSI médio, RSSI_Average. RSSI_Var é um parâmetro de camada de MAC que corresponde a uma estimativa da variância de RSSI. RSSI e RSSI_Average são variáveis codificadas de dois complementos de 1 byte. Sua faixa se estende a partir de - 128 dBm a +127 dBm. RSSI_Cov é uma variável positiva de 1 byte. KG é o ganho de Kalman, é um resultado intermediário na computação do filtro de Kalman e é um valor sempre menor do que um.
O RSSI médio proporciona uma indicação razoável da qualidade do sinal recebido, mesmo em ambientes contaminados com um desvanecimento de Rayleigh. Conforme explicado em uma outra seção deste documento, este RSSI médio participa na escolha do melhor pai de sincronização.
É tarefa da camada de MAC atualizar o LPD (atraso de propagação médio local) associado a cada vizinho e computar o GPD (atraso de propagação médio global) a partir do ponto final até o relê de célula através de cada vizinho. Estes valores são usados para a classificação e a seleção de vizinhos. Eles são usados para a seleção do melhor acesso para sincronização ou para a feitura de uma escolha entre diferentes células disponíveis. A camada de rede usará estes valores para escolher o melhor caminho para um enlace ascendente (roteamento de pacotes) .
Após toda transmissão de pacote que requer um reconhecimento, a camada de MAC saberá se a transmissão de pacote foi bem sucedida ou não. Se um reconhecimento positivo ou negativo for recebido, a transmissão será considerada bem sucedida. Se nenhum reconhecimento for recebido, a transmissão será considerada como tendo falhado. Se nenhum reconhecimento for recebido, a transmissão será considerada como tendo falhado. Para cada vizinho nesta lista de vizinho, a camada de MAC atualizará os valores de LPD individuais, conforme mostrado abaixo:
<formula>formula see original document page 156</formula>
Nestas equações, o parâmetro de MAC MAC_LPD_NAVG é um valor inteiro que determina a profundidade da janela média deslizante. Um fator de escalonamento de 16 foi introduzido para se permitir uma representação de inteiro de LPD. 0 valor máximo admitido para LPD é LPD_Max, qualquer valor de LPD calculado acima de LPD_Max devendo ser truncado para LPD Max. Nota 1: LPD é um inteiro e quando a computação dá um número com decimais, estes decimais devem ser truncados. Nota 2: o novo LPD deve sempre ser diferente do antigo (exceto quando os valores forem zero ou LPD_Max) . Se o novo LPD eqüivaler a um antigo e tiver havido uma falha, o novo LPD deverá ser incrementado por um; se tiver havido um sucesso de transmissão, então, o LPD deverá ser decrementado em um.
0 GPD (atraso de propagação médio global) é o atraso de propagação médio entre o ponto final e seu relê de célula associado. A rede computará este valor etapa por etapa a partir do relê de célula até o ponto final. Para se evitar uma confusão, pode-se considerar a notação a seguir: EP_GPD(X) ξ atraso de propagação global entre o ponto final e o mestre de célula se um tráfego for roteado através do vizinho X.
Um ponto final pode computar o GPD para o relê de célula através de um de seus vizinhos de acordo com a equação a seguir:
EP_GPD (X) ξ GPD de vizinho X + LPD entre o ponto final e o vizinho X + MAC_GPD_TD
MAC_GPD_TD é um parâmetro de camada de MAC introduzido para modelagem do atraso de propagação fixo através de cada nó da rede (veja o apêndice sobre o algoritmo de seleção de percurso). O melhor destes valores será denominado o GPD de ponto final.
GPD = Min{EP_GPD(X)} para todos os vizinhos X que forem pais registrados.
Este valor de GPD será incluído no cabeçalho de MAC para se tornar esta informação disponível para outros pontos finais. Os valores admitidos para GPD são os inteiros entre zero e 4095.
O nó deve atualizar seu GPD quando ele mudar de nível ou comutar para uma outra célula. O ponto final também precisa checar se seu GPD ainda não mudou em cada recepção de uma mensagem a partir de um de seus pais. Em uma visão mais geral, um ponto final sempre deve manter o GPD mais baixo que puder, dentre seus pais registrados (a partir da mesma célula).
Na partida, os valores de LPD na lista de vizinho devem ser inicializados de acordo com o valor de RSSI da primeira mensagem recebida a partir destes vizinhos. A inicialização segue esta regra:
<formula>formula see original document page 158</formula>
onde LPD_RSSI e LPD_Switch são parâmetros de camada de MAC.
Dito de uma outra forma, o presente assunto de protocolo provê vantajosamente um roteamento de enlace ascendente, sem requerer uma tabela de roteamento. Isso é obtido pelo endereçamento do principal percurso de enlace ascendente na rede em questão. Essa comunicação é usada para o transporte dos dados, a partir de todo nó da rede para um ponto de extração único. O desafio associado a esse recurso e presentemente obtido é para um nó para encontrar o percurso em direção ao ponto de extração, sem o conhecimento da topologia de rede, isto é, sem uma tabela de roteamento. Seguindo-se ao objetivo de atingir o ponto de extração em um tempo mais curto, o tráfego deve ser relativamente disperso, de modo a se evitarem picos, conforme o tráfego se tornar mais denso próximo do ponto de extração.
Conceitualmente, pelo presente assunto, o processo de sincronização proporcionou um nível a todo nó na rede. Esse nível representa o número de saltos entre o nó e o ponto de extração. Cada nó tem um certo número de vizinhos em um nível mais baixo (mais próximo do ponto de extração), denominados pais (ou responsáveis) do nó; um nível igual, denominados irmãos; e um nível mais alto (além do ponto de extração) denominados filhos.
De acordo com o presente assunto, um nó preferencialmente deve propagar uma mensagem de enlace ascendente para um de seus pais, o que significa um nó mais próximo da parte visível da rede. A mensagem no fim converge no ponto de extração. 0 pai selecionado para roteamento de uma mensagem de enlace ascendente pertence à lista de melhor pai. Pais pertencentes a essa lista são aqueles com o melhor GPD. A computação do atraso de propagação global, GPD, de outra forma é explicada aqui. O GPD mais baixo indica o percurso mais curto no tempo. O pai selecionado não necessariamente sempre é aquele com o melhor GPD. O nó envia mensagens de enlace ascendente randomicamente para um destes melhores pais com uma probabilidade de cada pai inversamente proporcional a seu GPD.
Vantajosamente, a prática desses aspectos do presente assunto obtém os benefícios de os percursos mais curtos serem selecionados, um conhecimento concernente apenas a vizinhos a um salto é suficiente para a obtenção, os nós não precisam de um conhecimento da rede inteira, de modo que não haja uma tabela de roteamento nos nós, o que resulta em economias relativamente grandes na memória requerida. Além disso, falando geralmente, o tráfego é disperso pela rede, devido à randomização entre os pais.
Um aspecto do presente assunto de protocolo vantajosamente prove uma distribuição e uma recuperação de relógio em tempo real, particularmente aplicável a uma rede, por exemplo, de outra forma com base no protocolo Aloha com intervalo. Falando geralmente, o tempo é presentemente dividido em intervalos de tempo (TS) e os nós enviam pacotes dentro desses intervalos de tempo. A freqüência usada para comunicação muda em cada TS de acordo com um padrão predeterminado: o hiperquadro. Um número, o número de intervalo de tempo (TSN), é incrementado em cada TS e rola quando atinge o comprimento de hardware, em cujo ponto o padrão de freqüência se repete. Um segundo número, o número de hiperquadro (HFN), também é associado e incrementado com cada hiperquadro.
Os nós são agrupados em uma célula em torno de um concentrador (ou nó de raiz) e estes 2 números são comuns a todos os nós na célula; desta forma, seus transmissores sempre estão regulados na mesma freqüência de RF. Estes 2 números serão usados pelos nós para a atualização de seu relógio "de tempo real" , mediante o recebimento de uma mensagem especifica, a qual se origina a partir do nó de raiz. Efetivamente, a distribuição do relógio será feita a partir do nó de raiz (ponto de extração dos dados de nós), o qual é conectado à internet e, assim, tem acesso a um relógio em tempo real acurado (por exemplo, no padrão NTP) .
Geralmente, os nós operam com cristais, o que resulta em uma acurácia limitada. O presente desafio, o qual é endereçado de forma bem sucedida aqui é atualizar periodicamente o tempo em cada nó, antes de seu relógio derivar além da acurácia desejada. Uma vez que a propagação não é instantânea, o sistema tem que levar em consideração o atraso de propagação.
A presente solução é difundir vantajosamente uma estampa de tempo (RITP) provida pelo relógio de tempo real escolhido. A criação da estampa de tempo sempre será feita no nível de nó de raiz, quando o TSN e O HFN da célula forem ambos nulos. Esta difusão também conterá o número de hiperquadro (HFN) correspondente à difusão inicial pelo nó de raiz; isto permitirá a detecção de um estouro para mais de HFN e adaptará o valor de RITP como uma conseqüência. Esta mensagem, seguindo o protocolo de difusão, atingirá todos os nós na célula; o valor máximo de HFN é projetado para a rolagem ser muito além do atraso de propagação máximo desta distribuição de relógio em tempo real.
Quando um nó recebe esta difusão, ele pode atualizar seu relógio de "tempo real" usando a fórmula a seguir:
Tempo absoluto = (TSN + HFN * hyperframelength) * Timeslot_Length + RITP
onde o comprimento de hiperquadro é expresso em número de intervalos de tempo e o comprimento de intervalo de tempo é uma unidade de tempo (note 150 ms no presente caso de exemplo) . Nota: se o HFN de recepção for mais baixo do que o HFN incluído na difusão, então, houve uma rolagem e a estampa de tempo RITP deve ser atualizada pela adição de valor de rolagem de HFN * hyperf rame_length * Timeslot_Length. Essa presente solução proporciona um tempo absoluto com uma resolução igual ao comprimento de intervalo de tempo.
Quando um nó apenas se sincroniza em uma nova rede, a estampa de tempo RITP (e o HFN correspondente) é proporcionada no reconhecimento de sincronização. Desta forma, o novo nó tem acesso ao tempo real sem esperar pela próxima difusão de ITP. Nota: isto assume que a difusão de RITP é feita a cada vez em que HFN = TSN = 0, para se evitar mais de uma rolagem do número HFN.
Esses aspectos do presente assunto de protocolo vantajosamente provêem uma forma simples, mesmo usando-se uma arquitetura de Aloha com intervalo, para a distribuição de um relógio de tempo real para todos os nós com uma resolução de um intervalo de tempo (apesar do atraso de propagação). Eles também permitem uma recuperação rápida do relógio de tempo real imediatamente mediante uma sincronização para uma nova rede.
Portanto, pelo presente assunto, um gerenciador de tempo na camada de MAC é realizado com o uso de vários contadores. A Figura 16 ilustra a estrutura global desses presentes contadores de estrutura de manutenção de tempo de protocolo, enquanto o que vem a seguir prove alguma descrição adicional para cada um desses contadores.
Quanto - ao temporizador de contagem de Aloha com intervalo (SACT) no começo de cada intervalo de tempo esse temporizador é carregado com um valor correspondente ao comprimento de intervalo de tempo padrão, MAC_TS_Length.
Quanto este temporizador atinge o valor zero, um novo intervalo de tempo começa. A cada MAC_Xdrift_LeapTS intervalos de tempo, o SACT é carregado com o valor de MAC_TS_Length mais uma pequena correção para compensação da deriva do cristal (veja a descrição de intervalos de tempo de pulo no capítulo de correção de deriva).
O SACT é localmente implementado com uma resolução especificada pelo parâmetro MAC_FW_Accuracy, mas quando os valores de SACT são trocados entre os pontos finais ou incluídos no cabeçalho de MAC para fins de sincronização, o SACT é definido como uma resolução de MAC_SACT_Resolution ps.
O conteúdo do contador de intervalo de tempo é o número de intervalo de tempo (TSN). No começo de cada intervalo de tempo, este contador é incrementado. Seu valor vai de zero a MAC_HF_Length -1. MAC_HF_Length é o número de intervalos de tempo em um hiperquadro.
O contador de intervalo de tempo pode ser dividido em dois contadores em cascata, o contador de seqüência de salto básica e o contador de superseqúência. O conteúdo do contador de seqüência de salto básica indica a posição em uma seqüência de salto básica. No começo de cada intervalo de tempo, este contador é incrementado. Seu valor vai de zero a MAC_Number_of_Channels -1. MAC_Number_of_Channels é o número de canais usados em uma seqüência de salto básica.
O conteúdo do contador de superseqüência indica a posição na superseqüência de salto. Quando uma seqüência de salto básica é completada, este contador é incrementado. Seu valor vai de zero a (MAC_HF_Length/MAC__Number_of_Channels - 1)·
A estampa de tempo de ITP relativa (RITP) é inicializada para zero na partida. Uma vez que uma informação de tempo absoluto seja obtida a partir da rede ou da aplicação, este contador pode ser atualizado. Em cada estouro para cima do contador de hiperquadro, a estampa de tempo de ITP relativa deve ser atualizada, conforme explicado em outro lugar aqui. Esta estampa de tempo pode ser implementada com o formato de NTP (Protocolo de Tempo de Rede) padrão ou com uma versão resumida do formato de NTP padrão, de acordo com a acurácia requerida e com a faixa. A presente Figura 17 geralmente representa um formato de estampa de tempo de ITP (Protocolo de Tempo Itron) padrão. A partir da estrutura de gerenciamento de tempo de protocolo presente referenciada acima, podem-se definir vários valores de tempo. Dois desses dados aqui serão úteis para várias finalidades, e eles são o tempo absoluto e o tempo relativo.
O tempo absoluto corresponde ao relógio de tempo real da aplicação. Ele pode ser usado para datar qualquer evento de uma forma absoluta. Sua resolução é o comprimento de intervalo de tempo. Em termos de contadores de manutenção de tempo, o valor de tempo absoluto é dado pela fórmula já referenciada aqui acima.
Em contraste, o tempo relativo usado para medição das durações em uma escala de tempo menor do que a faixa do relógio de MAC. Este tempo tem uma resolução mais alta, porque usa o SACT. Em termos de contadores de manutenção de tempo, o valor de tempo relativo é dado por:
Tempo relativo = (TS_Length - SACT * "unidades de tempo de SACT") + (TSN + HFN * MAC_HF_Length) * TS_Length As unidades de tempo de SACT dependem da implementação e são dadas pelos parâmetros MAC_FW_Accuracy ou MAC_SACT_Resolution. A faixa deste relógio relativo é dada por:
Faixa de relógio de MAC = MAC_HFC_Max * MAC_HF_Length *
MAC_TS_Length
Em cada estouro para cima do contador de hiperquadro, a estampa de tempo de ITP relativa precisa ser atualizada,
conforme se segue: (Novo valor de RITP) = (Valor antigo de RITP) + (Faixa de relógio de MAC)
Uma operação de geração de uma estampa de tempo absoluta é necessária quando a camada de MAC tem que informar à camada de LLC que um novo valor de relógio de tempo real foi entregue pela rede. O valor de estampa de tempo computado nessa instância é o tempo absoluto no momento em que a camada de MAC envia para as camadas superiores a indicação da chegada da nova estampa de tempo, conforme se segue:
Estampa de tempo de ITP absoluta = (TSN + HEN * MAC_HF__Length) * MAC_TS_Length + RITP
Com relação à geração de um valor para a estampa de tempo de ITP relativa, quando a aplicação comunica um valor de estampa de tempo de ITP para a camada de MAC, a camada de MAC precisará referenciar esta estampa de tempo para o relógio de MAC (TSN e HFN) e armazenará o valor resultante em seu registrador de estampa de tempo de TIP relativa. Isto correrá, por exemplo, em um relê de célula, quando a aplicação precisará ajustar os relógios de tempo real da célula. O valor de RITP será computado com a equação a seguir:
RITP = (valor de estampa de tempo de ITP) - (TSN + HFN * MAC_HF_Length) * MAC_TS_Length
Com relação ao presente assunto de protocolo de Serviços de Sincronização de Tempo, há duas formas de propagação do tempo ao longo de uma célula inteira: em uma fase de sincronização e por uma atualização periódica. O presente assunto de tempo absoluto será usado dentro do presente assunto de protocolo de rede em si (na camada de MAC) e no nível de aplicação (neste exemplo, medição de energia).
Cada relê de célula tem um cliente de NTP o qual permite que ele receba uma estampa de tempo de NTP a partir da WAN. Ele usa seu valor de NTP para a atualização de sua RITP. 0 relê de célula envia periodicamente mensagens de difusão de ITP para a célula inteira, com exatamente o mesmo processo como uma mensagem de difusão "regular". Sua mensagem de difusão de ITP contém a informação de RITP, base da regeneração de tempo em pontos finais. A cada vez em que um EP recebe uma mensagem como essa, ele lê e atualiza a RITP e encaminha a mensagem para seus filhos.
A segunda forma de aquisição do campo de RITP é durante o processo de sincronização. Quando um EP desperta após uma falha de potência, ele não tem mais qualquer noção de tempo. 0 campo de RITP é dado dentro de uma mensagem SYNC ACK após o EP requisitar - uma sincronização com um vizinho sincronizado. Assim, tão logo um EP seja sincronizado, vantajosamente ele conhece o tempo pelo presente assunto de protocolo.
Em um aspecto do presente assunto, um objetivo vantajosamente alcançado é ajustar os relógios de tempo real em todo nó de uma célula. Não há um argumento de entrada requisitado. A operação é descrita no contexto de um serviço que é usado apenas em um relê de célula. A camada de MAC de relê de célula constrói um pacote de difusão de ITP. O cabeçalho de MAC deste pacote contém o valor da RITP em conjunto com o HFN no momento em que o pacote é criado. Este pacote é difundido com as regras de difusão usuais definidas neste protocolo. Esta difusão permitirá que cada nó destinatário atualize sua própria estampa de tempo de ITP relativa. Os nós destinatários usarão o valor de HFN incluído no pacote para a detecção de um possível estouro para cima do relógio de MAC, desde a criação do pacote de difusão de ITP. A faixa de relógio de membro de carne deve ser muito mais longa do que o tempo de percurso esperado de um pacote através da rede de malha, de modo a se evitarem ambigüidades.
Em um outro aspecto do presente assunto, um objetivo vantajosamente alcançado é a provisão de um serviço o qual permite que a camada de aplicação (através de LLC e NET) atualize a estampa de tempo de ITP relativa da camada de MAC. O argumento de entrada requisitado envolve a estampa de tempo de ITP absoluta. A operação de novo é descrita no contexto de um serviço que é usado apenas em um relê de célula. A camada de MAC usa a estampa de tempo de ITP absoluta para computação de um valor de estampa de tempo de ITP relativa. A camada de MAC então atualiza seu registrador de RITP com seu valor computado (veja "Geração de um valor para a estampa de tempo de ITP relativa" acima) . Este serviço usualmente é chamado antes de uma difusão de ITP. É distinto do serviço de difusão de ITP, de modo a se evitar um envelhecimento descontrolado de uma estampa de tempo em um pacote esperando em uma fila.
Ainda um outro aspecto do presente assunto é a obtenção vantajosa de um objeto de indicar para a camada de aplicação (através de LLC e NET) que uma difusão de ITP foi recebida. Os argumentos de saída requisitados são a estampa de tempo de ITP absoluta, a RITP, e valores de HFN a partir do cabeçalho de MAC. Então, ela compara o valor de HFN no cabeçalho de mensagem com seu próprio HFN. Isto permite que a camada de MAC detecte um possível estouro para cima do contador de hiperquadro, desde a criação do pacote de difusão de ITP. Se nenhum estouro para cima de HFC tiver ocorrido, ela escreverá o valor de RITP em seu próprio registrador de RITP. Se um estouro para cima tiver ocorrido, ela incrementará o valor de RITP com a faixa do relógio de MAC e escreverá o resultado em seu registrador de RITP. A camada de MAC então computa uma estampa de tempo de ITP absoluta (veja "Geração de uma estampa de tempo absoluta" acima) e envia para a camada de LLC uma indicação com esta estampa de tempo de ITP absoluta como argumento. Esta indicação informa à camada de LLC que a RITP foi atualizada na camada de MAC e proporciona à camada de LLC o valor de uma estampa de tempo que pode ser usada para a atualização do relógio de tempo real da aplicação. O pacote de difusão de ITP então é encaminhado para os filhos de ponto final de acordo com as regras de difusão usuais. Os valores de RITP e HFN recuperados a partir do cabeçalho de MAC de pacote de difusão de ITP também são enviados para a camada de LLC com a finalidade de permitir a reconstrução do pacote para o acompanhamento da difusão.
Um outro objetivo vantajosamente alcançado com o presente protocolo em questão permite que um ponto final obtenha o valor da RITP e o valor do contador de hiperquadro a partir de seu pai na sincronização. Essa operação usualmente é uma parte do processo de sincronização, conforme discutido de outra forma aqui. Contudo, em nome da presente clareza, é simplesmente notado que quando um ponto final recebe um reconhecimento para sua requisição de sincronização, ele atualizará sua RITP e seu HFN a partir da informação contida naquele reconhecimento.
Um aspecto importante em uma rede de malha usando uma seqüência de salto de freqüência é o processo de sincronização. De fato, uma vez que todo EP na célula conhece a seqüência de canal e o TS atual na seqüência, eles precisarão periodicamente manter essa informação atualizada. Devido à deriva de relógio, essa informação pode se tornar corrompida com o tempo. Uma ressincronização do relógio de todo EP, portanto, é necessária.
Quando a rede em questão é comutada para ligada pela primeira vez, nenhum componente conhece o começo de intervalos de tempo e qual freqüência usar. Como em todos os sistemas sincronizados, um metrônomo ou uma operação equivalente é necessário. 0 relê de célula (ou mestre de célula) é o componente preferido no presente assunto de protocolo, porque sempre é considerado como "sincronizado". Para os outros pontos finais, pelo presente assunto, a sincronização é hierárquica. Os pontos finais os quais podem ouvir o relê (mestre de célula) se tornam sincronizados e, então, é a sua vez de sincronizar seus vizinhos. Durante esse processo, um nível é dado a cada ponto final, o qual indica a quantos saltos eles estão do relê de célula (mestre de célula).
Um relê tem um nível "1"; um ponto final não sincronizado tem um nível "0"; e um ponto final que esteja a N saltos do relê de célula tem um nível "N+1" . Os respectivos níveis relativos ao presente protocolo de sincronização são representados na presente Figura 18.
Para resumir a terminologia referenciada de outra forma aqui, um ponto final o qual é de: • Nível N se comparado a um nível de EP de N-χ, χ> = 1, é denominado um filho (ou criança)
• Nível N se comparado a um nível de EP de N+x, χ>=1, é denominado um pai (ou responsável)
• Nível N se comparado a um nível de EP de N é denominado um irmão (ou irmão de qualquer sexo)
• Nível 0 é denominado um órfão
A presente Figura 19 representa os aspectos de sincronização de hierarquia do presente assunto, de modo que um ponto final mantenha sua sincronização a partir de qualquer vizinho sincronizado que respeite as condições a seguir:
• O vizinho deve pertencer à mesma célula (mesma seqüência de canal)
• O vizinho deve ser um pai, isto é, deve ter uma posição hierárquica mais alta (um número de nível mais baixo).
Essas condições proporcionam a possibilidade de um ponto final ter mais de uma fonte para informação de sincronização. Isto é possível porque, no fim, todo mundo na célula terá a mesma base de tempo. Isto também permite que um ponto final de nível N se sincronize com um ponto final de nível N-2 (veja as condições para mudança de nível referenciadas de outra forma aqui).
O nível máximo em uma célula é de 63. Ele é limitado pelo número de bits (6) alocado a este campo nas mensagens. Como resultado das regras acima, um EP de nível 63 não pode ser usado para sincronização.
A presente Figura 20 representa vários aspectos do presente assunto de protocolo conforme se refere a uma ressincronização entre pontos finais (EPs). Pelo presente assunto, um EP vantajosamente se ressincroniza a cada vez em que recebe uma mensagem de um de seus pais, ao recomputar o começo de seu próximo intervalo de tempo. Em cada começo de cada intervalo de tempo, um temporizador de contagem regressiva denominado Temporizador de Contagem Regressiva de Aloha com Intervalo, SACT, é regulado com o valor MAC_TS_Length. Quando esse temporizador atinge 0, a camada de MAC comuta para o próximo intervalo de tempo. 0 processo de ressincronização consiste na recomputação do valor do SACT para alinhamento dos intervalos de tempo dos filhos naqueles dos pais. Esta ressincronização é realizada com o algoritmo a seguir:
• 0 comprimento do preâmbulo (incluindo o campo de SFD) é pré-definido e a taxa de bit é conhecida. Portanto, a duração, dl, do preâmbulo pode ser prontamente computada.
• No lado de transmissor, o remetente indica rio cabeçalho de MAC o valor de SACT, SACTlO, correspondente ao começo da transmissão física do pacote (isto é, o tempo entre a transmissão do primeiro bit do pacote e a próxima mudança de intervalo de tempo, conforme medido em unidades de tempo de SACT).
• No lado de receptor, assim que o SFD é detectado, a camada física do ponto final destinatário lê seu valor de temporizador, SACT20, e deduz SACT2 0+dl, o valor de SACT quando o remetente começou a transmissão de sua mensagem.
• A camada física indica para a camada de MAC que recebeu uma mensagem em SACT2 0+d1. A camada de MAC também lê o valor de temporizador SACT10 contido no cabeçalho de MAC.
• Então, em qualquer momento, a camada de MAC pode atualizar seu valor de temporizador, SACT2, pela correção adicionada ASACT.
SA CT'2 = SACT2 + ΔSACT
ΔSACT = SACT]0 - (SA CT 20 + dX)
Vantajosamente, pelas presentes operações, o ponto final se auto-ajusta ao próximo intervalo de tempo, o que compensa a deriva interna do dispositivo. Ao seguir esse presente processo em cada mensagem recebida a partir de um ponto final de nível mais alto, o ponto final drasticamente diminui a probabilidade de perder sua sincronização.
A cada vez em que um ponto final recebe uma mensagem de um ponto final vizinho, a camada de MAC grava dois valores de tempo na tabela de vizinho: o valor de SACT lido a partir do cabeçalho de MAC de remetente (SACT10 acima) e o tempo de recepção do pacote. Estes valores então podem ser usados em qualquer momento quando o ponto final decidir se sincronizar com aquele vizinho.
0 SACT é definido com uma resolução de MAC_SACT_Resolution ps.
Uma datação de mensagens recebidas e transmitidas deve ser acurada o bastante para permitir que o presente protocolo funcione apropriadamente e, especificamente, para o processo de ressincronização funcionar corretamente. O relógio de cristal do sistema deve se escolhido em ± MAC_Crystal_Accuracy ppm e o firmware tem que datar a mensagem em ± MAC_FW_Accuracy ps. A datação de uma mensagem recebida deve ser feita pela tomada de um instantâneo do temporizador de contagem regressiva SACT quando o campo de SFD for detectado pela camada PHY, conforme é explicado de outra forma aqui.
Um remetente também deve datar a mensagem e incluir o valor de SACT no cabeçalho de MAC. É uma tarefa difícil computar precisamente o SACT no momento exato em que a camada PHY enviará o último bit. De fato, nesse ínterim, a camada de MAC terá que construir o cabeçalho, computar a CRC e, então, proporcionar a mensagem para a camada PHY; e, então, a camada PHY terá que adicionar seu cabeçalho e conf igurar o transmissor de RF. É um aspecto do presente assunto que seja preferível para uma dada implementação do mesmo (tal como na produção do firmware real a ser usado) estimar um tempo de pior caso entre o momento da datação e a transmissão planejada, e regular um temporizador com esse tempo. Durante essa alocação de tempo, as camadas de MAC e PHY devem ter tempo suficiente para preparação do pacote. A camada PHY então esperará durante o tempo remanescente e enviará o primeiro bit assim que o temporizador atingir o valor definido.
Para uma implementação em particular usando uma abordagem de transceptor produzido em série, é notado que uma datação da recepção de SFD tipicamente é a coisa mais simples e preferida a fazer. Se for mais conveniente para uma dada implementação datar em um outro momento dentro da mensagem, o usuário estará livre para fazê-lo pelo presente assunto, desde que se lembre de levar em consideração o comprimento da mensagem.
Quando um ponto final recebe uma mensagem, ele pode computar facilmente o começo do próximo intervalo de tempo. Mas essa informação sozinha não é suficiente, uma vez que o canal no próximo intervalo de tempo não é conhecido naquele momento. 0 ponto final encontrará esta informação no cabeçalho de MAC. Três campos são importantes para o processo de sincronização. 0 primeiro é o nível do remetente: uma (re)sincronização é permitida apenas com os pais. Os dois outros campos são o número de intervalo de tempo e o endereço de célula. Como todo ponto final pode computar a seqüência de canal a partir do endereço de célula contido no cabeçalho, e devido ao fato de o número de intervalo de tempo informar onde o remetente está na hiperseqüência, o destinatário pode encontrar o canal que o remetente usará no próximo intervalo de tempo.
Esses três campos estão presentes em todas as mensagens: sinais de orientação ou outras mensagens. Assim, toda mensagem pode ser usada para sincronização. 0 campo de número de intervalo de tempo tem um outro uso. Mesmo se um ponto final receber uma mensagem em um canal adjacente, ele saberá o canal real no qual a mensagem foi enviada.
Um EP se ressincroniza a cada vez em que recebe uma mensagem de um pai de SYNC, qualquer que seja a natureza da mensagem. Se não houver um tráfego, mensagens dedicadas (presentemente referido como sinais de orientação) são enviadas periodicamente por todo EP sincronizado. Se o tráfego for denso o bastante, se comparado com a periodicidade de sinal de orientação padrão, os sinais de orientação não serão enviados. Pode ser visto como um temporizador com o valor inicial
MAC_Beacon_Periodicity_SYNC. A cada vez em que um pacote é enviado, o temporizador é reiniciado a partir do começo. Se o temporizador atingir vO', um sinal de orientação será enviado.
Vários parâmetros permitem a computação de uma periodicidade de sinal de orientação de EPs sincronizados.
O mais importante é a acurácia de relógio do EP. É dependente principalmente na acurácia do cristal (ou oscilador) e do relógio de firmware. Um outro parâmetro é o número de sinais de orientação que se pode assumir que um sistema possa perder, devido a colisões, emperramentos, etc. O último parâmetro é a deriva máxima que o sistema está autorizado a ter entre 2 niveis. Para essa computação, pode-se considerar o pior caso, quando o EP tem apenas um pai SYNC.
<formula>formula see original document page 175</formula>
Exemplo:
TS_Margin = 15 ms
Clock_Accuracy = ±20 ppm
Max Nb_of_Missed_Beacons = 3 sinais de orientação perdidos TS_Length = 15 0 ms
-> Beacon_Periodicity_SYNC = 625 TS (isto corresponde a 1 min 34s)
Em uma situação de tráfego baixo com muitos pontos finais transmitindo sinais de orientação periódicos, há uma probabilidade significativa de dois pontos finais escolherem o mesmo intervalo de tempo e subintervalo de tempo para transmissão de seus sinais de orientação. Esta probabilidade aumenta aproximadamente conforme o quadrado do número de pontos finais e estaria próximo de um em um agrupamento de 100 pontos finais. Isto levaria a colisões recorrentes entre aqueles sinais de orientação. Para se evitar esta situação, o tempo de transmissão real dos sinais de orientação deve ser randomizado em +20%, isto é, uma janela de em torno de 125 intervalos de tempo (para MAC_Beacon_Period_SYNC = 625) , enquanto se mantém a periodicidade média definida acima.
O indicador de tamanho de célula, CSI, é um campo de 4 bits contido em cada camada de MAC. Este valor de campo é regulado pelo mestre de célula, dependendo do tamanho da célula (determinado pelo número de entradas em uma tabela de roteamento de mestre de célula de NET) . Isto requererá uma mensagem interna a partir da camada de NET do mestre de célula para sua camada de MAC. Este campo, como o GPD, propagar-se-á com cada mensagem do mestre de célula. Em cada mensagem recebida de um de seus pais, ou de pontos finais os quais foram pais, o nó atualiza seu CSI olhando para o valor de cabeçalho de MAC. Um ponto final (outro além do mestre de célula) sempre mantém o valor mais alto de CSI dentre seus pais pertencentes à mesma célula.
Os algoritmos para se escolher uma célula durante uma fase de descoberta e comutar a célula consistirão na seleção do melhor pai de acordo com seu termo. 0 CSI é um dos parâmetros usados para a determinação deste termo. Os valores para o CSI são dados na seção de camada de rede.
Alternativamente, pelo presente assunto, a propagação de CSI deve ser com base na última mensagem recebida a partir de um pai. Essa abordagem evita manter este campo extra na tabela de vizinho de cada EP. A transigência é que durante a propagação de um novo valor de CSI, haverá muito mais rebotes (ao contrário torna mais rápido aumentar o valor e desacelerar para diminui-lo).
Um vizinho de um ponto final é chamado um pai de sincronização potencial (ou pai de SYNC potencial) para aquele ponto final, se ele estiver em conformidade com todas as condições a seguir:
• O vizinho é conhecido pelo ponto final, isto é, ele foi ouvido pelo menos uma vez e ainda está gravado na tabela de vizinho.
• O vizinho já está sincronizado (seu nivel é diferente de zero).
• O vizinho tem um nível abaixo de 63 (o qual é o nível máximo admitido em uma célula).
• O vizinho é registrado em uma célula (bit de RS = 1) .
• O vizinho é um ponto final autorizado, isto é, um ponto final que não foi marcado com um indicador tipo de fIag como proibido (o bit Sync_Forbidden na tabela de vizinho deve ser zero).
• O vizinho tem pelo menos uma conectividade fraca. Grau de Conectividade > 1 (valor de CD > 1).
• O vizinho pertence a uma célula a qual não é proibida.
• O vizinho pertence a uma célula a qual não é plenamente cheia (um valor de CSI diferente do valor máximo) . Nota: esta condição não é considerada se o nó já for um membro desta célula cheia.
O caráter proibido associado a uma célula é regulado pela camada de API. Ele pode ser regulado se o usuário decidir que duas células próximas nunca devem autorizar pontos finais a partir da outra célula ou se uma célula estiver cheia. Uma célula pode ser reautorizada pela camada de API. Esta informação também será reinicializada se o medidor ficar não sincronizado por um tempo longo, definido pelo parâmetro MAC_Unsynchronized_Timeout.
Através de um processo de seleção descrito mais tarde, o pai de sincronização potencial mais adequado é escolhido para se tornar o pai de sincronização (ou pai de SYNC para resumir). Se este vizinho responder positivamente à requisição de sincronização, ele se tornará o pai de SYNC real do nó.
Deve ser destacado que as condições de pai de SYNC potencial são avaliadas em um dado tempo. Se um pai de SYNC potencial (ou um pai de SYNC) não for ouvido durante o MAC Neighbor_Timeout, ele será removido da tabela de vizinho de MAC e não será mais considerado um pai de SYNC potencial (ou pai de SYNC).
Quando um ponto final se torna sincronizado com uma célula, parte de seus pais potenciais será de pais reais e alguns outros poderiam ser irmãos ou filhos. Por outro lado, alguns pais poderiam não se qualificar para serem pais de SYNC potenciais. Os pais que também são pais de SYNC potenciais serão chamados pais saudáveis. Obviamente, por definição, um ponto final não sincronizado não tem pai algum, ele podendo ter apenas pais de SYNC potenciais. A Figura 21A representa esquematicamente pais de SYNC potenciais e pais saudáveis para um nó sincronizado.
0 grau de conectividade (CD) é uma variável que mede a conectividade de um nó com a rede. O grau de conectividade pelo presente assunto é representado pela presente Figura 2IB. 0 valor de CD de um nó depende apenas do número de pais de SYNC potenciais que ele tem dentre seus vizinhos. Se o ponto final ainda não tiver sido sincronizado, todos os pais de SYNC potenciais serão considerados para a computação de CD. Por outro lado, se o ponto final for sincronizado, apenas os pais e filhos serão levados em consideração. Note que um ponto final sincronizado deve ter pelo menos um pai (nivel inferior) , de modo a ser considerado tendo conectividade (CD > 0). A tabela abaixo mostra como um valor é atribuído a CD como uma função do número de pais de SYNC potenciais. Este grau é indicado na maioria dos cabeçalhos de MAC e compartilhado com a vizinhança. Será usado por outros para decisões de sincronização.
De modo a manter seu relógio sincronizado com a rede, um ponto final deve receber sinais de orientação ou mensagens freqüentes o bastante de seus pais. Portanto, há uma necessidade de se avaliar a taxa média na qual um ponto final recebe mensagens de um dado vizinho. Isto terá um papel importante quando se decide qual vizinho pode atuar como um pai de SYNC eficiente. Os vizinhos que são apenas ouvidos uma vez em um tempo serão julgados pais de SYNC potenciais ruins, se comparados com outros que são ouvidos regularmente. O indicador de taxa de recepção (para resumir, RXI) é fácil de implementar e prove uma indicação da taxa na qual as mensagens são ouvidas a partir de um vizinho, embora não seja uma medida exata da taxa de recepção real.
Uma variável de um byte está associada a cada vizinho na tabela de vizinho. Nós chamamos esta variável o RXI do vizinho X e escrevemos RXI(X). Estes RXI são gerenciados de acordo com as regras a seguir: • Mediante o recebimento de uma mensagem a partir de X,
incrementar seu RXI
• RXI(X) Min [RXI(X) + RXI_Increment, 255]
• Em cada começo de hiperquadro, decrementar todos os RXI
• RXI(X) <- RXI(X) * RXIJDecay, para todo X e {tabela de vizinho}
Valores altos de RXI indicam que a freqüência de recepção de mensagem é alta. Portanto, vizinhos com valores de RXI altos têm uma vantagem no processo de seleção de pai de SYNC.
Outra discussão aqui reflete como um EP mantém sua sincronização a partir do relógio de célula pelo presente assunto, o que assumiu para esse ponto de discussão que o EP já foi conectado. Na partida ou após uma perda de sincronização, um EP é considerado como não sincronizado e entra em uma assim denominada Fase de Descoberta.
Em outras palavras, pelo presente assunto, este aspecto tem a ver com a provisão de um arranjo de descoberta de rede, onde um novo nó sem conhecimento prévio de seu ambiente é capaz de estabelecer um enlace com uma rede existente. Quando da ativação, esse novo nó preferencialmente transmitirá um sinal de orientação de descoberta por vários canais em sucessão e, então, irá para um modo de escuta para escutar qualquer resposta. 0 sinal de orientação de descoberta transmitido inclui uma informação quanto a um canal especifico no qual o novo nó ouvirá. Quando nós sincronizados ouvem o sinal de orientação de descoberta, eles transmitem uma mensagem para o novo nó incluindo uma informação necessária para o novo nó se sincronizar com a rede. A mensagem transmitida pode incluir tempo, freqüência, identificador de rede, etc. e é transmitida no novo nó indicando freqüência e em tempos randômicos em uma janela de escuta. O novo nó então pode coletar uma informação e escolher a melhor rede dentre os critérios desejados e sincronizar com o nó de acesso escolhido na rede.
Em uma rede de salto de freqüência, os nós que recém foram acionados e começam a partir do zero não têm idéia de seu ambiente. Eles precisam se conectar e sincronizar com uma rede, o que é complicado pelo fato de não saberem em qual freqüência e em qual tempo a rede opera. A fase de descoberta do presente assunto de protocolo é uma abordagem algorítmica para se permitir que o nó rapidamente analise seu ambiente e procure a melhor rede a que ele pode se conectar, sem perturbar a rede de operação.
Falando amplamente, benefícios adicionais desse presente assunto incluem que um novo vizinho encontre uma conexão com uma rede em um tempo muito curto, todas as redes da vizinhança são descobertas, e enquanto isso as redes operando na vizinhança não são perturbadas em suas atividades regulares.
Mais especificamente, como o tráfego é muito baixo dentro de uma célula e como a célula está continuamente comutando de um canal para um outro, pode levar um tempo longo para que um ponto final não sincronizado intercepte uma mensagem de um sincronizado. Para aceleração deste processo, o ponto final não sincronizado envia sinais de orientação de descoberta sucessivamente em todos os canais. A ordem dos canais segue a seqüência de salto gerada por uma ID de célula de 0. Há um sinal de orientação de descoberta por canal no sistema. O canal do primeiro sinal
randomicamente para se garantir que dois pontos finais não sincronizados não escolham o mesmo na partida. Os sinais de
MAC_Discovery_Beacon_Period ms.
Cada sinal de orientação de descoberta contém no cabeçalho de MAC o número de sinais de orientação de descoberta remanescentes (campo de NDB) a enviar, e o canal de escuta (campo RxC) . Após enviar todos os sinais de orientação de descoberta, o ponto final entra em um modo de escuta durante o MAC_Listening_Window_Length. 0 canal de escuta é o mesmo que aquele usado para o primeiro sinal de orientação de descoberta. Há uma alta probabilidade de os EPs sincronizados no alcance de rádio do EP receberem pelo menos um destes sinais de orientação de descoberta. A recepção de um destes sinais de orientação de descoberta. A recepção de um destes sinais de orientação de descoberta os força a enviar um "sinal de orientação forçado" no canal requerido dentro da janela de escuta. Como todo EP sincronizado na vizinhança terá o mesmo padrão, a janela de escuta deverá ser longa o bastante para conter a maioria das respostas. A fórmula abaixo proporciona o comprimento da janela de escuta, para o caso em que o número de colisões entre as respostas de vizinho é minimizado. de orientação de descoberta deve ser computado orientação de descoberta são enviados a cada
<formula>formula see original document page 182</formula> MAC_Nb_of_Sub_TS = 6 Sub_TS MAC_TS_Length = 15 0 ms
->MAC_Listening_Window_Length = 2,5 segundos ou 17 TS
A presente Figura 22 representa um exemplo de fase de descoberta com um número de seqüência de salto de freqüência básico 0 para uma modalidade operativa em PHY- FHSS-NA-915.
Durante o estado de escuta, uma informação sobre todos os vizinhos que responderam e, principalmente, uma informação de sincronização (endereço, nível, tempo, canal, endereço de célula, GPD e RSSI) é salva na tabela de vizinho do ponto final. No fim do estado de escuta, se não houver uma resposta, a próxima fase de descoberta será começada após um tempo randômico (veja abaixo). O canal do primeiro sinal de orientação desta nova fase de descoberta é o próximo, na seqüência de salto, após aquele usado na janela de escuta prévia. Este processo é repetido por um período de MAC_Min_Discovery_Phase_Period modulado por um tempo randômico (o valor padrão máximo é de 100 ms) para se evitarem colisões repetitivas entre pontos finais não sincronizados. Entre o fim da janela de escuta e o começo da nova fase de descoberta, o ponto final pode ficar no modo de escuta. Este processo pára no fim de um período de escuta, se o ponto final tiver recebido pelo menos uma resposta de um sinal de orientação de descoberta potencial (se for uma partida a quente, então, esta resposta deverá vir de sua célula preferida; veja a presente discussão sobre partida a quente versus a frio).
Na situação em que um ponto final não é bem sucedido na sincronização com uma célula após MAC_Max_Nb_of_Discovery_Phases fases de descoberta, o período de fases de descoberta será aumentado de MAC_Min_Discovery_Phase_Period para
MAC_Max_Discovery_Phase_Period. Isto evitará um que um órfão polua a banda de RF com mensagens inúteis. O período será reinicializado para seu valor inicial, se o ponto final for bem sucedido na sincronização.
No fim da janela de escuta, se pelo menos uma resposta válida tiver sido recebida, o EP irá para a próxima etapa. Uma mensagem de resposta ou de dados de um vizinho será considerada como válida para fins de sincronização, se ela se adequar às condições de pai de SYNC potencial. Pode ser destacado que pontos finais não sincronizados, pontos finais não registrados (RS = 0), pontos finais de nível 63, pontos finais não conectados (CD =0) ou pontos finais de uma célula cheia (CSI = valor máximo) não têm permissão para enviarem sinais de orientação forçados. Mas, há uma chance de um ponto final na fase de descoberta ouvir uma mensagem pretendida para um outro ponto final, em cujo caso, deve verificar as condições de pai de SYNC potencial.
A próxima etapa para este ponto final que tenta se tornar sincronizado é escolher o melhor acesso à rede. Para esta seleção, o ponto final considerará todos os vizinhos de que ele recebeu uma resposta ou de que escutou casualmente um pacote, a menos que eles tenham sido descartados pelas razões mencionadas acima. Dentre estes vizinhos, ele escolherá o melhor acesso usando um critério com base nos princípios a seguir:
• CSI Baixo: células com um número menor de pontos finais serão preferidas em relação àquelas que sejam mais ocupadas.
• EPGPD Baixo: vizinhos com valores de GPD baixos serão preferidos. 0 EP_GPD de um vizinho é o atraso de propagação médio global entre o ponto final e o mestre de célula através do vizinho selecionado.
• Bom Nível: um vizinho mais próximo do mestre de célula será preferido a um vizinho distante mais saltos do mestre de célula.
O valor de um vizinho, bem como seu CSI, é indicado no cabeçalho de MAC. Os valores de EP_GPD, por outro lado, precisam ser computados. Matematicamente, EP_GPD = GPD do vizinho (conforme reportado em seu cabeçalho de MAC) + LPD + MAC_GPD_TD.
O atraso de propagação local (LPD) de um vizinho usualmente é computado a partir do registro de acompanhamento de tentativas passadas de comunicação com aquele vizinho. Este algoritmo é explicado em um capitulo dedicado. Durante a fase de descoberta, a computação de um LPD, contudo, é impossível, porque o ponto final ainda não trocou mensagens suficientes com o vizinho para acumular uma informação estatisticamente relevante. Neste caso, uma estimativa do LPD com base na leitura de RSSI é usada.
De modo a se fazer uma seleção com base em uma combinação dos princípios mencionados acima, nós introduzimos um termo para a caracterização da capacidade de um vizinho de atuar como uma fonte de sincronização adequada:
SYNC_Disc_Merit = EP_GPD * MAC_SYNC_Disc_Weight_GPD + MAC_SYNC_Disc_Weight_Leve 1 * LVL + MAC_SYNC_Disc_Weight_CSI
* CSI São definidos três parâmetros de camada de MAC, MAC_SYNC_Disc_Weight_GPD, MAC_SYNC_Disc_Weight_Level e MAC_SYNC_Disc_Weight_CSI. Os valores destes parâmetros dependerão da importância que se quer dar ao GPD, ao nível ou ao tamanho de célula no processo de seleção. Se alguém regular os dois últimos parâmetros para zero, apenas o GPD será usado para a seleção do ponto de sincronização.
O processo de seleção para o melhor acesso pode ser resumido conforme se segue:
1. Em primeiro lugar, o ponto final computa o EP_GPD para cada vizinho de que ele recebeu uma resposta ou de que escutou casualmente um pacote (desde que o vizinho seja um pai de SYNC potencial).
2. Para cada vizinho, o ponto final computa o termo para sincronização, SYNC_Disc_Merit.
3. O ponto final seleciona o vizinho com o valor mais baixo de SYNC_Disc_Merit e sincroniza seus intervalos de tempo e a seqüência de freqüência com ele. A tabela de vizinho deve ser gerenciada cuidadosamente neste processo, para se permitir que o ponto final recue e se ressincronize com um outro vizinho, se necessário.
4.0 ponto final então tem que pedir a este vizinho permissão para se sincronizar com ele. Para esta finalidade, ele envia uma mensagem específica chamada uma requisição de sincronização (SYNC Request) (Requisição de SYNC).
5. Se esta requisição não for positivamente reconhecida, o ponto final deve indicar com um indicador tipo de flag o vizinho como proibido (regular o bit Sync_Forbidden para 1 na tabela de vizinho) e prosseguir para a etapa 3 acima com o próximo vizinho válido na lista com o melhor termo. Várias situações podem levar a esta falha:
a. O vizinho não responde à requisição de SYNC. A camada de MAC de ponto final repetirá a requisição (por um número de tentativas definido por Max_Nb_of_SYNC_Request e com um período mínimo dado por MAC_SYNC_Request_Period mais alguma randomização por uns poucos intervalos de tempo) , antes de concluir que o vizinho não é alcançável.
b. O vizinho responde com um SYNC NACK para indicar que recusa a requisição de sincronização. Neste caso, o ponto final deve concluir imediatamente que seu vizinho não é adequado para sincronização.
6. Se o vizinho aceitar (ao enviar um SYNC ACK) , o ponto final atualizará seu nível e comutará para o modo sincronizado. O SYNC ACK também contém o número de hardware atual na célula (HFN) e o ITP relativo (RITP). O RITP permitirá que o ponto final conheça o tempo absoluto, sem esperar por uma mensagem de difusão de ITP (veja a seção de Tempo).
A tabela da presente Figura 23 proporciona um exemplo para uso do termo com três vizinhos e MAC_SYNC_Disc_Weight_GPD = 1,
MAC_SYNC_Disc_Weight Levei = 50. Neste exemplo, o vizinho preferido é o terceiro.
A discussão precedente descreveu o mecanismo para uma partida a frio, isto é, o ponto final não sincronizado não tinha um conhecimento prévio da rede. Quando um ponto final o qual já está sincronizado e registrado junto a uma célula experimenta uma falha de potência e, então, é ligado de novo, ele pode usar seu conhecimento da rede para recuperar mais rapidamente seu estado a partir de antes da falta de potência. Este processo é denominado uma partida a quente.
Para uma partida a quente, haverá uma noção de célula preferida no nível de camada de MAC. A célula preferida é uma com que o ponto final foi registrado antes da falta de potência. Em primeiro lugar, o ponto final considerará a si mesmo já registrado (bit de RS regulado para 1) e tentará conectar apenas com sua célula prévia. Se após um número de fases de descoberta (definido por
Warm_Start_Discovery_Duration) ele não tiver conseguido fazê-lo, ele considerará as outras células e recomeçará a fase de descoberta, sem uma célula preferida, como em uma partida a frio.
Durante a partida a quente, os sinais de orientação de descoberta contêm o endereço da célula com que o ponto final deseja se sincronizar. Isto é para impedir os pontos finais pertencentes a outras células de enviarem sinais de orientação forçados e inundarem o enlace em cada fase de descoberta por nada. Este campo é regulado para zero durante uma partida a frio.
É muito importante que o vizinho selecionado cheque sua própria conectividade com a rede, antes de reconhecer uma requisição de SYNC. Antes de reconhecer uma requisição de SYNC, um ponto final deve checar se ele recebeu uma mensagem recente de um pai saudável durante os últimos MAC SYNC Father_Request_Beacon_Threshold intervalos de tempo. Se este não for o caso, ele deverá requisitar um sinal de orientação a partir do pai saudável com o melhor LPD:
MAC_SYNC_Father_Request_Beacon_Threshold < Beacon_Periodicity_SYNC
Mediante o recebimento de uma Requisição de SYNC, um ponto final responderá com um SYNC ACK (ou SYNC NACK) ou enviará uma requisição de sinal de orientação para um de seus pais saudáveis, se ele tiver recebido uma mensagem recente de qualquer um deles. Neste último caso, o ponto final não responderá à requisição de sincronização imediatamente, mas esperará pelo vizinho para retransmitir sua requisição. No momento em que o mesmo vizinho requisitar de novo uma sincronização, o ponto final deve ser capaz de aceitar a requisição, porque ele terá recebido mensagens recentes de seus próprios pais saudáveis. Neste caso, o ponto final enviará um SYNC ACK.
O ponto final que recebeu a requisição de sincronização precisa enviar o reconhecimento de sincronização ou requisitar um sinal de orientação no intervalo de tempo seguindo-se à recepção da Requisição de SYNC.
O pai que foi requisitado para enviar um sinal de orientação tem que enviá-lo em um dos próximos intervalos de tempo seguindo-se à recepção da requisição de sinal de orientação, antes de MAC_SYNC_Request_Period intervalos de tempo terem decorrido. Se este nó já tiver planejado enviar uma outra mensagem (que tem a mesma informação de cabeçalho que um sinal de orientação) nesta janela, ele não precisará enviar um sinal de orientação. O ponto final do qual foi pedida uma sincronização enviará um SYNC NACK nos casos a seguir:
• O ponto final não está mais sincronizado (nível 0).
• O ponto final tem um nível 63.
• O ponto final não está registrado em uma célula (bit de RS = 0) .
• O ponto final não tem conectividade. Grau de Conectividade = 0 (CD = 0) . O grau de conectividade deve ser atualizado após uma recepção de Requisição de SYNC, principalmente para se recusar uma sincronização no caso em que um ponto final tenta se sincronizar com seu próprio filho (antigo).
Mediante a recepção de um SYNC NACK de um vizinho, seu bit Sync_Forbidden deve ser regulado para 1, o que impede requisições adicionais de sincronização de serem enviadas para este vizinho. Entre fases de descoberta sucessivas, a tabela de vizinho não deve ser limpa, de modo a reter esta informação.
O bit proibido associado a um vizinho deve ser limpo para 0, se o nó notar uma mudança nestes parâmetros:
• O vizinho muda seu nível (exceto para 0) .
• O vizinho comuta para uma outra célula.
• O vizinho se torna registrado (bit de RS de 0 para 1).
• O vizinho muda seu grau de conectividade (CD de 0 para um valor positivo).
• O vizinho é novo na tabela de vizinho.
O bit proibido de todos os vizinhos na tabela deve se limpo para 0, se:
• O nó mudar seu nível (exceto para 0) .
• O nó comutar para uma outra célula. Um exemplo de sincronização completo é provido com referência à presente Figura 24. EP6 é um medidor novo e tem três vizinhos em duas células diferentes. EP4 é o melhor ponto final com que se sincronizar. Neste exemplo, há apenas sete canais diferentes.
Se o único pai de SYNC requisitar uma sincronização a partir de um de seus filhos, o filho terá que recusar imediatamente. O filho também deve perceber que ele perdeu sua sincronização. Um medidor, o qual recusou uma sincronização, tem que ser marcado (Sync_Forbidden = 1), para não ser perguntado mais tarde de novo. Se as propriedades deste medidor mudarem (nível, célula, ativação), a marca será removida.
O presente assunto de protocolo vantajosamente provê Requisições de Sinal de Orientação e resolução de bit de RS para se evitarem rotas circulares. Esse assunto se aplica primariamente ao ambiente de uma rede de árvore em que os nós são organizados em células com um concentrador (ou nó de raiz) na "cabeça" de cada célula. Cada nó tem um nível associado a seu lugar na célula. Conforme referenciado aqui de outra forma, o nó de raiz é de nível 1 e sempre é sincronizado (por definição) . De modo a levar seus dados para o nó de raiz, um nó deve ser sincronizado na célula correspondente.
Dito de uma outra forma, o presente processo de sincronização requer uma checagem manual entre um nó sincronizado e um outro nó. Um nó o qual se sincroniza em um outro se torna seu filho e o outro nó se torna o pai do primeiro. O novo nível de nó é um a mais do que aquele de seu pai. Portanto, todos os nós têm um nível acima de 1. Os nós do mesmo nível são denominados irmãos. 0 grupo de pais, irmãos e filhos de um nó é denominado como seus vizinhos. Cada nó mantém uma tabela de seus vizinhos.
O problema resolvido de forma bem sucedida pelo presente assunto se refere a quando um nó (nó 1) perde sua sincronização e pede a um de seus irmãos ou filhos uma sincronização. Se um destes nós (por exemplo, o nó 2) aceitar dar uma sincronização para o nó 1, então, ele mudará de nível (nível de nó 2 + 1) . Após isso, um outro nó (por exemplo, o nó 3) , o qual tinha o nó 1 como pai pode perceber que este não é mais o caso (uma vez que o nível de nó 1 agora está sobre seu próprio nível) , e pode tentar encontrar um novo pai com o qual se sincronizar. Especificamente, ele pode pedir ao nó 1, o qual aceitará. Se o nó 3 tiver sido o pai do nó 2, ele começará a encontrar um novo pai. Deixado por si, esse processo pode se tornar um laço sem fim com nós pedindo uma sincronização para um outro sem um percurso real para o concentrador (e, assim, sem ser realmente sincronizado). A parte principal deste problema é o atraso entre o novo estado de um nó e o tempo em que seus vizinhos percebem isso.
A solução do presente assunto é com base em uma informação de Sincronização, a qual está presente em todas as mensagens; Sinais de Orientação (os quais são pacotes com apenas a informação de sincronização) ; e com base em requisições de sinal de orientação (as quais são pacotes requisitando um sinal de orientação a partir de um vizinho).
Uma das partes principais de informação para sincronização toma a forma de um bit (o bit de RS) , o qual indica se um nó ainda tem pais (isto é, o bit de RS regulado para 1) ou não. Este bit está presente em todos os pacotes, porque esta informação deve ser atualizada tão rapidamente quanto possível e assim deve fazer uso de qualquer comunicação. Um nó aceitará dar uma sincronização apenas se ele tiver recebido uma mensagem relativamente recente de um pai (com um bit de RS regulado para 1).
Quando um nó recebe uma requisição de sincronização (SYNC REQUEST), ele checará se recebeu uma mensagem recente de um de seus pais (com o bit de RS regulado para 1). Se ele descobrir esse pai, então aceitará dar a sincronização (SYNC_ACK). Caso contrário, ele enviará uma requisição de sinal de orientação para um de seus pais com o bit de RS regulado para um. Este pai enviará um sinal de orientação com toda sua informação de sincronização (incluindo o bit de RS) em resposta. 0 nó pedindo uma sincronização repetirá sua demanda e, desta vez, o nó recebendo a requisição deve ter recebido o sinal de orientação e deve ser capaz de enviar um reconhecimento de sincronização (SYNC_ACK). Se um nó não tiver um pai com um bit de RS regulado para 1, ele recusará uma sincronização (SYNC_NACK).
A requisição de sinal de orientação permite atualizar a informação de vizinhos quando eles considerarem que ela não é recente o bastante, especialmente no caso em que um outro nó pediu a eles uma sincronização (eles devem estar seguros de ainda terem uma boa conectividade, antes de aceitarem). Essa presente solução vantajosamente prove uma forma relativamente rápida de propagação da informação de sincronização entre nós, desse modo se evitando que eles criem uma rede circular virtual sem uma raiz real. A requisição de sinal de orientação ajuda a atualizar o conhecimento de um nó sobre seus vizinhos, se a informação for considerada antiga demais.
A presente Figura 24 ilustra um exemplo de configuração, enquanto a presente Figura 25 representa um processo de sincronização, ambas em relação a um exemplo de sincronização completa pelo presente assunto de protocolo. Com referência adicional às presentes Figuras 24 e 25, o EP6 é um novo medidor e tem 3 vizinhos em duas células diferentes. EP4 é o melhor EP para sincronização (melhor nível, melhor GPD). Neste exemplo, há apenas 7 canais diferentes.
EP6, na ativação, está no nível 0, não sincronizado, e entra em sua fase de descoberta. Ele envia sinais de orientação sucessivos nos 7 canais, e seus 3 vizinhos recebem, cada um, um sinal de orientação, porque tempo e freqüência combinam em um momento de sorte. Após o envio de todos os sinais de orientação, o EP6 entra em um modo de escuta em uma freqüência que é indicada nos sinais de orientação anteriores. Os 3 vizinhos reagem a este estímulo ao enviarem um sinal de orientação "forçado" uns poucos intervalos de tempo (randômicos) mais tarde na freqüência requerida. O EP6, o qual ouve no canal verde ("green channel") recebe estes sinais de orientação e salva a informação de sincronização. Deve ser notado que durante esta fase de escuta, o EP3 pode interceptar mensagens dos outros EPs. Devido à operação do cabeçalho de MAC, o EP3 seria capaz de salvar sua informação de sincronização, já que está conectado a seus 3 vizinhos atuais.
No fim desta fase de escuta, é o momento da sincronização. Assim sendo, EP6 ajusta seus intervalos de tempo em EP4, e requisita uma sincronização. EP4 checa se ainda tem uma conexão com o relê de célula 1, seu pai de SYNC, ao requisitar um sinal de orientação, e tão logo receba o sinal de orientação, envia um SYNC ACK para EP6 . EP6 se torna sincronizado e se torna de nivel 3 no número de célula 1.
Note que os EPs números 3, 4 e 5 interromperam suas seqüências de canal durante 1 TS para enviarem um sinal de orientação forçado no canal verde. Isto não é um problema, porque se um outro EP os tiver ouvido neste momento, teria sido lido no cabeçalho o canal que teria que ser usado (endereço de CELL, e número de TS) . O fato que é um outro canal que foi escolhido é transparente para a camada de MAC.
A presente Figura 26A representa um exemplo de uma Configuração Inicial, e a presente Figura 26B representa um exemplo de um novo ponto final, ambas ilustrativas de circunstâncias de um ponto final encontrar um melhor ponto final para fins de comunicação, pelo presente assunto conforme discutido adicionalmente aqui.
Cada ponto final deve indicar na tabela de vizinho de MAC qual de seus pais enviou o SYNC ACK para a concessão de direitos de sincronização. O indicador tipo de flag SYNC Father (pai de SYNC) serve para esta finalidade.
Pode acontecer de a comunicação de um nó com seu pai de SYNC ou as características do pai de SYNC se deteriorarem até o ponto em que um novo pai de SYNC precisa ser encontrado. Dois casos precisam ser considerados. 1. A comunicação com o pai de SYNC se deteriora, mas o pai de SYNC ainda é um pai saudável, porque está em conformidade com as condições de pai de SYNC potencial. Neste caso, quando o ponto final roda seu processo de seleção de pai de SYNC periódico, ele pode escolher descartar o novo pai de SYNC e pegar um novo, o qual terá um acesso melhor à rede.
2. 0 pai de SYNC desaparece ou perde seu status de pai de SYNC. Nós chamamos a isso uma perda de pai de SYNC, e ocorrerá se:
• 0 pai de SYNC permanecer silencioso por tempo demais e desaparecer da tabela de vizinho (MAC_Neighbor_Timeout).
• 0 pai de SYNC não está mais em conformidade com as condições de pai de SYNC potencial.
• 0 pai de SYNC muda seu nível.
• 0 pai de SYNC se move para uma outra célula. Neste caso, um processo de seleção de pai de SYNC é
imediatamente disparado. Pode ser notado que o processo de seleção pode levar ao mesmo pai de antes, a seleção sendo feita de acordo com critérios de pai de SYNC potencial e o termo em questão.
Se um nó mudar seu nível após a seleção de um novo pai de SYNC, então, todos os indicadores tipo de flag deverão ser removidos, exceto pelo último regulado (para o pai que recém enviou o SYNC ACK e permitiu que o ponto final mudasse seu nível) . Um ponto final deve ter apenas um pai com o indicador tipo de flag de pai de SYNC regulado. Neste caso, o ponto final é considerado sincronizado. Note que um pai que não seja bom para sincronização ainda pode ser usado para mensagens de roteamento (se ainda for um pai).
De modo a se comparar o valor relativo de pontos finais vizinhos como pais de sincronização, considere um termo referente a SYNC_Merit, o qual é definido por:
SYNC_Merit = EP_GPD + SYNC_Penalty_LPD + SYNC_Penalty_RXI + SYNC_Penalty_CD
Este termo é o único computado para os vizinhos que são pais de SYNC potenciais (veja as condições de pai de SYNC potencial). O componente principal deste termo é o EP_GPD. Termos adicionais são introduzidos para diminuição da probabilidade de escolha de alguns vizinhos que possam ser menos adequados como pais de sincronização. O termo SYNC Penalty_LPD é necessário porque o LPD tem uma faixa finita. Quando o LPD de um vizinho é truncado para seu valor máximo, LPD_Max, o atraso de propagação real não é conhecido e uma constante é adicionada ao termo, para se levar em consideração o risco de selecionar aquele vizinho com um pai de SYNC. O termo SYNC_Penalty_LPD é definido por:
<formula>formula see original document page 197</formula>
O termo SYNC_Penalty_RXI é necessário para se evitar selecionar como pai de SYNC um ponto final cujo indicador de taxa de recepção seja baixo demais, e é definido por:
<formula>formula see original document page 197</formula> O termo SYNC_Penalty_CD introduz uma preferência por vizinhos que tenham melhor grau de conectividade com a finalidade de se tornar a rede mais estável e confiável, sendo definido por:
<formula>formula see original document page 198</formula>
0 caso em que CD = 0 foi mencionado aqui em nome da clareza. Um vizinho com CD = 0 não é, por definição, um pai de SYNC potencial e o termo nunca será computado nesse caso.
Periodicamente, um ponto final rodará o processo de seleção de novo pai de SYNC para ver se um pai de SYNC melhor se tornou disponível. Estes processos de seleção periódicos devem ocorrer em torno de uma vez por hiperquadro. Eles serão implementados de forma tal que pontos finais diferentes em uma célula rodem o processo em temos diferentes, desse modo se evitando pontos finais em demasia enviando uma requisição de SYNC ao mesmo tempo. Um número de intervalo de tempo randômico poderia ser usado para esta finalidade. Por outro lado, quando um ponto final perde seu pai de SYNC, ele deve começar imediatamente o processo de seleção para um novo. O processo de seleção para este novo pai de SYNC é descrito abaixo.
A tabela de vizinho será analisada para a classificação dos vizinhos que combinem com as condições de pai de SYNC potencial. Se pontos finais pertencentes a outras células aparecerem nesta lista, eles deverão ser removidos da lista. Os pontos finais de outras células, quando eles são escutados ao acaso, são lidados de acordo com o processo de decisão de comutação de célula descrito neste documento. O termo SYNC_Merit então será computado para todos os pais de SYNC potenciais na lista. O vizinho com o melhor SYNC_Merit (valor mais baixo) é denominado aqui X. O vizinho que tinha o melhor SYNC_Merit no momento do processo de seleção prévio é denominado XP. Se X for diferente de XP, um contador, SYNC_Top, será inicializado para zero. Se X for idêntico a XP, o contador SYNC_Top será incrementado. Se um vizinho decidir ficar no topo da lista de pai de SYNC potencial por SYNC_Top_N hiperquadros ou mais, ele estará autorizado a se tornar o novo pai de SYNC, desde que esta mudança traga um melhoramento de SYNC_Merit maior do que SYNC_Merit_Hyst1. Em qualquer taxa, se escolher X como o novo pai de SYNC trouxer um melhoramento no termo maior do que SYNC_Merit_Hyst2, o ponto final deverá selecionar X como o novo pai de SYNC. Uma descrição detalhada etapa por etapa deste processo de seleção é dada abaixo.
· Etapa 1: Os vizinhos são classificados de acordo com as condições de pai de SYNC potencial para a feitura de uma lista de pais de SYNC potenciais.
Se esta lista estiver vazia, então,
Descartar todas as mensagens de MAC pendentes e ir para a fase de descoberta
Caso contrário, se a lista contiver pelo menos um pai de SYNC potencial,
Ir para a etapa 2
Fim do se • Etapa 2: Computar o termo, SYNC_Merit, para cada pai de SYNC potencial.
• Etapa 3: 0 pai de SYNC potencial com o menor valor de SYNC_Merit é identificado (X).
Se o ponto final tiver perdido seu pai de SYNC potencial, então,
• Etapa 4: Selecionar X como o novo pai de SYNC (menor SYNCJMerit). Ir para a etapa 7.
Se o ponto final ainda tiver seu pai de SYNC, então,
• Etapa 5: Seleção de pai de SYNC com histerese temporal de acordo com o algoritmo a seguir:
If X í XP, then
SYNC_Top = 0
XP = X
Else if X = XP, then
SYNC_Top <- SYNCJTop +1
Comentário: SYNCJTop é o único incrementado uma vez em todo hiperquadro.
<formula>formula see original document page 200</formula>
X is selected as new SYNC father Go to step 7
Else
Keep the former SYNC father End if
End if • Etapa 6: Procurar um pai de SYNC melhor com o algoritmo:
Se SYNC_Merit(X) + SYNC_Merit_Hyst2 < SYNC_Merit(SYNC father), então
Selecionar X como o novo pai de SYNC Caso contrário, manter o pai de SYNC anterior
Fim do se
• Etapa 7: Se um novo pai de SYNC tiver sido selecionado, enviar uma requisição de SYNC para X e esperar pelo reconhecimento (as requisições de SYNC são detalhadas em uma outra parte deste documento).
Se a requisição tiver sido reconhecida positivamente, então,
Parar (processo completado)
Caso contrário, se a requisição não é reconhecida positivamente (reconhecida negativamente ou não reconhecida de forma alguma) e o ponto final tiver um pai de SYNC válido,
Abortar o processo
Caso contrário, se a requisição não é reconhecida positivamente e o ponto final não tem mais um pai de SYNC,
Ir para a etapa 1
Fim do se
Durante a etapa 7, se o ponto final decidir se sincronizar com um novo pai, ele deve:
• Manter sua sincronização de MAC
• Manter seu nível (em seu cabeçalho)
• Recusar qualquer requisição de sincronização: enviar SYNC NACK
• Recusar qualquer mensagem: enviar NACK (veja gerenciamento de tráfego)
• Indicar em suas mensagens que não está mais sincronizado pela regulagem do bit RS para zero.
Muitos mestres de célula (relês) podem coexistir no campo. Estes mestres de célula podem fazer parte da mesma rede ou podem pertencer a redes diferentes ou a serviços de utilidade pública diferentes. Uma afiliação de um ponto final a uma rede é indicada pelo campo de UID no cabeçalho de MAC e pelo valor de SFD no cabeçalho de PHY. Um ponto final nunca se moverá para uma outra rede, mas poderá comutar para uma outra célula pertencente à mesma rede. Um serviço de utilidade pública pode instalar mestres de célula adicionais em algumas áreas, de modo a se aumentar a capacidade de ritmo de transferência de dados ou para se desafogar uma célula grande. Mestres de célula adicionais também proverão percursos de roteamento alternativos que contribuirão para a qualidade do serviço. Para se permitir que o tráfego seja disperso uniformemente através das células disponíveis, um ponto final o qual já está conectado a uma célula deve ter a possibilidade de comutar para uma outra célula, com ou sem uma intervenção externa.
O método de pedir manualmente a um medidor para comutar para uma outra célula é muito simples, se um dos pontos finais pertencentes à nova célula estiver em um alcance de rádio. O usuário deve enviar apenas uma mensagem para o ponto final que contará a ele que a célula atual agora é proibida e que a nova é preferida. Então, o ponto final entrará em uma fase de descoberta para procurar por uma outra célula e, então, se sincronizar com ela.
Um ponto final também deve ser capaz de comutar para uma outra célula automaticamente, se ele considerar que terá uma melhor posição na nova célula e, portanto, um melhor acesso à WAN. Esta comutação tem que ser feita com algum cuidado, porque pode perturbar uma ramificação inteira da rede. Por esta razão, as condições para mudança para uma outra célula devem ser estritas, particularmente se tudo funcionar apropriadamente na atual.
Antes de comutar para uma outra célula, um ponto final deve conhecer, obviamente, que pelo menos um representante desta outra célula está na vizinhança. Como a camada física está, por padrão, no modo de escuta, acontece de tempos em tempos de um ponto final receber uma mensagem de uma outra célula. De fato, mesmo se as seqüências de salto não forem as mesmas, elas nunca serão totalmente ortogonais, porque elas usam o mesmo conjunto de canais e elas não sincronizadas com a mesma base de tempo. Ocasionalmente, um ponto final transmitirá uma mensagem quando os canais de ambas as células estiverem alinhados, e se alguns pontos finais pertencentes à outra célula estiverem no alcance de rádio, elas ouvirão a mensagem. Com apenas uma mensagem ouvida ao acaso de uma célula adjacente, devido aos parâmetros contidos no cabeçalho de MAC, um ponto final terá toda a informação para comutar para aquela célula adjacente.
Se o ponto final julgar que a célula adjacente não provê um acesso melhor à rede, ele descartará a informação. Se este acesso for melhor, o ponto final poderá escolher se ressincronizar com a célula adjacente. O critério para declaração que um ponto final de uma outra célula é um melhor acesso à rede é com base em vários parâmetros:
• Baixo CSI. A menor célula será preferida ã maior, de modo a se evitar ter duas células adjacentes com uma cheia e outra vazia.
• GPD Baixo. O acesso ao GPD menor será preferido (o valor usado aqui é o GPD entre o ponto final e o mestre de célula através do vizinho, o qual é referido como EP_GPD).
• Nível Baixo. Uma célula que prove acesso com menos saltos ao mestre de célula será preferida.
De modo a se fazer uma seleção com base em uma combinação dos princípios mencionados acima, nós introduzimos um termo para comparação das células umas com as outras.
CELL_Merit = MAC_CELL_Weight_GPD EP_GPD + MAC_CELL_Weight_Level * LVL + MAC_CELL_Weight_CSI * CSI Aqui são definidos três parâmetros de camada de MAC, MAC_CELL_Weight_GPD, MAC_CELL_Weight_Level e MAC_CELL_Weight_CSI. Os valores destes parâmetros dependerão da importância que se dá ao GPD, ao nível ou ao tamanho de célula no processo de decisão de comutação de célula. Se alguém regular os dois últimos parâmetros para zero, apenas o GPD será usado para a comparação das células. Ao escutar ao acaso uma mensagem de uma célula adjacente, o ponto final computará o termo CELL_Merit para a nova célula e também para sua célula atual. A condição para uma comutação de célula é: CELL Merit (célula nova) < CELL Merit (célula atual) MAC_CELL_Switch_Hysteresis,
onde nós introduzimos um novo parâmetro de camada de MAC, MAC_CELL_Switch_Hysteresis, cujo papel é evitar que um nó continuamente comute para trás e para frente entre duas células. Uma vez que o ponto final tenha determinado que a nova célula é melhor do que a atual, tem-se que garantir que seja aceito pela nova célula, antes de realmente comutar. Para esta finalidade, o ponto final pedirá ao ponto final de uma outra célula uma sincronização. A requisição de SYNC e o SYNC (N)ACK serão trocados, conforme é feito em outras situações, exceto pelo fato de o ponto final precisar ajustar sua freqüência e o tempo de transmissão, considerando que a outra célula opera em uma seqüência de salto diferente.
Uma vez que o novo pai do ponto final deixa a célula responder com um SYNC ACK, a camada de MAC precisa informar a camada acima e fica em sua célula antiga durante MAC_CELL_Leaving_Process_Duration segundos, antes de deixá- la definitivamente. Nesse ponto, as diferentes camadas precisam liberar seus buffers e suas ações pendentes. Após a comutação ser feita, a camada de MAC informa a camada acima de novo. Este sincronismo é necessário para que a camada NET deixe o registro pelo envio de uma mensagem de Notificação de Saida de Célula de NET.
Um exemplo de um processo completo de comutação de célula é conforme se segue:
o O ponto final ouve ao acaso uma mensagem a partir de um ponto final pertencente a uma outra célula,
o O ponto final salva os parâmetros de vizinho em sua tabela de vizinho. O ponto final checa se este vizinho se adéqua às condições de pai de SYNC potencial. Caso não, o processo de comutação de célula é abortado,
O ponto final coraputa as figuras de mérito de comutação de célula para esta célula atual e para a nova célula. Se as figuras de mérito forem favoráveis à nova célula, o ponto final segue adiante com o processo de comutação de célula,
O ponto final envia uma Requisição de SYNC para o vizinho, em um canal forçado e em um sub-TS forçado.
Se o vizinho concordar e se ele tiver uma boa conectividade com seu pai, ele enviará, então, um reconhecimento de SYNC, mais uma vez em um canal forçado e em um sub-TS forçado. Se o vizinho não concordar, ele enviará um reconhecimento negativo e o processo de comutação de célula será abortado. Se o vizinho precisar checar sua conectividade com seu pai, ele requisitará um sinal de orientação e o ponto final tentando comutar de célula não receberá nenhum reconhecimento imediato.
Se necessário, o ponto final repetirá sua requisição de SYNC até receber um reconhecimento ou até o número máximo de novas tentativas ser atingido. Neste último caso, o processo de comutação de célula é abortado.
Uma vez que o SYNC ACK seja recebido, o ponto final descarta todas as mensagens (em todas as camadas) de sua célula anterior,
A camada de MAC informa a outra camada e começa um temporizador com uma duração de MAC_CELL_Leaving_Process_Duration segundos. o Uma vez que o temporizador expire, o ponto final descarta todas as mensagens (em todas as camadas) de sua célula anterior,
o O ponto final se sincroniza com o vizinho a partir da nova célula. (Tenha cuidado, o número de hiperquadro pode ter mudado durante o período de transição). Durante este processo, até o reconhecimento de SYNC ser recebido e durante o período de transição o ponto final deve lidar com suas atividades de comunicação em sua célula atual.
• Manter esta sincronização de MAC com a célula atual
• Manter seu nível
• Não iniciar uma comutação de célula com uma outra célula, ou uma mudança de pai de SYNC com um outro ponto final.
• Trabalhar conforme usual, manter as outras atividades.
Ainda um outro aspecto do presente assunto de protocolo vantajosamente se refere a um laço de controle de retorno, que pode ser usado para correção de imperfeições de relógios de cristal e para manutenção de uma sincronização em uma rede de malha de espectro de dispersão de salto de freqüência (FHSS).
Conforme discutido de outra forma aqui, o presente protocolo é baseado em um espectro de dispersão de salto de freqüência (FHSS) para melhor imunidade à interferência e para se estar em conformidade com os regulamentos de rádio em alguns países. Em um sistema de FHSS pelo presente assunto, todos os nós saltam sua freqüência de canal de acordo com a mesma seqüência pseudo-randômica, de modo a ser perfeitamente sincronizado para recepção e transmissão.
A performance de um sistema como esse é com base na capacidade de cada nó ser capaz de manter essa forma de sincronização ao longo do tempo. Isto é a razão porque o hardware de nó requer uma referência de tempo de cristal com boa estabilidade. Devido ao fato de essas referências de tempo serem dispendiosas, é útil implementar um mecanismo de compensação acionado por software para melhoria da estabilidade no tempo dos nós.
Na presente rede de exemplo, conforme discutido de outra forma aqui, uma estrutura tipo de malha é provida, onde o relê de célula é a raiz da malha e o metrônomo da rede. Como uma regra, essa informação de sincronismo é propagada para longe da raiz até os nós de célula. No presente assunto de protocolo, a cada vez em que um nó se comunica com um outro nó mais próximo da raiz, ele realinhará seu relógio para estar em sincronização com a rede. Além disso, essas correções de relógio consecutivas vantajosamente têm a média calculada no tempo, são filtradas e processadas para se proporcionar uma informação sobre quão rápido o relógio de nó está correndo com respeito ao relógio médio dos nós mais próximos da raiz. Esse presente recurso permite uma correção de software do ritmo de relógio de nó que o colocará em sintonia com a rede por um longo período de tempo. Portanto, falando geralmente, o presente assunto provê os benefícios de permitir o uso de cristais de custo relativamente baixo nos nós de rede, mas com uma estabilidade no tempo aumentada da rede.
Mais especificamente, a presente Figura 27 ilustra uma distribuição típica de ressincronizações e correções de deriva de cristal no tempo, pelo presente assunto.
Conforme referenciado de outra forma aqui, uma boa sincronização é a base do presente protocolo, motivo porque uma limitação inerente àquele aspecto de outra foram viria principalmente da acurãcia do cristal. De modo a se limitar o tráfego e para evitação de colisões internas, tão poucos sinais de orientação de sincronização quanto possível são enviados. Contudo, como resultado, em condições de tráfego baixo, o número de oportunidades para ressincronização do relógio com um pai, portanto, será relativamente pequeno.
Como uma conseqüência, cada ponto final geralmente terá um deslocamento de relógio com o nível superior. Para números de nível relativamente maior, esse deslocamento se tornaria significativo em relação ao relógio de relê de célula. Isto poderia levar a uma perda de sincronização, se fosse deixado o deslocamento crescer acima de algum limite. Mais ainda, como um ponto final pode ressincronizar seu relógio com vários pontos finais pais, um mecanismo de cálculo de média poderia ser utilizado vantajosamente.
Uma abordagem do presente assunto como uma solução é antecipar a deriva do oscilador de cristal local com respeito aos relógios de pai. Se essa deriva for assumida como sendo constante (que mostrou ser uma boa hipótese, se a temperatura não mudar muito rapidamente), um procedimento de compensação eficiente poderá ser implementado. Portanto, ao invés de esperar pela próxima ressincronização, o ponto final pode ajustar seu comprimento de intervalo de tempo para diminuição do próximo valor de ressincronização de relógio. O algoritmo de compensação usa uma filtração de passa baixa para lidar com múltiplos percursos de sincronização e para evitação de instabilidades. A descrição detalhada desse algoritmo é discutida em outro lugar aqui.
Sempre que o receptor ressincronizar seu relógio local, dois valores são gravados: o valor da correção, o qual é Clock_Correction(k), e o tempo desta ressincronização, o qual é Resync_Time (k). Este tempo é dado pelo valor do relógio de tempo real do sistema no momento da ressincronização. O parâmetro k é usado aqui para numeração das sucessivas ocorrências de ressincronização. Para estes dois valores e com o conhecimento do tempo de ressincronização prévio, teoricamente é possível avaliar a deriva relativa do oscilador de cristal local, Xdrift. Para ser útil para fins de compensação de deriva de cristal, estas avaliações devem ser acuradas.
Cada valor de correção de relógio pode ser considerado como sendo o resultado de duas contribuições. A primeira é uma deriva lenta devido a uma diferença entre a freqüência de cristal local e a freqüência de cristal média nos pontos finais pais. A segunda contribuição é um deslocamento de tempo randômico ocorrendo no momento em que um tempo de curso de pacote é estimado. Isto é resumido na equação a seguir:
<formula>formula see original document page 210</formula>
onde ôt(k) é um erro randômico devido à incerteza no tempo de propagação do pacote a partir da camada de MAC de transmissor para a camada de MAC de receptor, quando um número k de ressincronizações for realizado.
Para redução da contribuição de erros randômicos, correções de relógio sucessivas são preferencialmente somadas, conforme se segue:
<formula>formula see original document page 211</formula>
É prontamente entendido pela presente exposição que, na avaliação da deriva de cristal, a contribuição destes erros randômicos se tornará crescentemente menor conforme sucessivas correções de relógio forem somadas, conforme se segue:
<formula>formula see original document page 211</formula>
Por esta razão, os valores de correção de relógio sucessivos são somados até eles cobrirem um tempo maior do que o valor mínimo especificado pelo parâmetro de camada de MAC MAC_Xdrift_Tmin. Uma vez que este valor de tempo seja excedido, a deriva de cristal pode ser avaliada com o seguinte:
<formula>formula see original document page 211</formula>
A faixa de soma deve respeitar a condição:
Resync_Time(k(n)) - Resync_Time{k{n- I)) > ΑΊΑC _ Xdrift _ Tmin
onde MAC_Xdrift_Tmin é escolhido grande o bastante para ter:
<formula>formula see original document page 211</formula> Xdrift_accuracy é a acurácia almejada do algoritmo (em torno de 1 ppm) . MAC_Xdrift_Tmin também deve ser muito maior do que o intervalo entre dois intervalos de tempo de pulo (conforme discutido em outro lugar aqui), de modo que o processo de integração no tempo ocorra para suavização de pequenos defeitos de compensação de deriva de cristal.
A presente Figura 28 representa em formato esquemático um algoritmo de compensação de deriva de relógio local para a prática pelo presente assunto de protocolo, enquanto a presente Figura 29 representa (também em formato esquemático) um filtro de passa baixa para correção de deriva de cristal, tudo de acordo com o presente assunto.
A estimativa referenciada aqui com referência a uma deriva de referência não será usada diretamente para compensação da deriva de oscilador de cristal. De modo a calcular a média por várias fontes de sincronização e ficar livre de flutuações, um filtro de passa baixa (veja a presente representação da Figura 29) será implementado. Este filtro de passa baixa é definido por:
Xdrift _ filiin) = AχXdrifi(η)+BxXdrift _ fih{n-1),
onde Xdrift_filt(n) é a estimativa de deriva de cristal filtrada e A, B são os coeficientes de filtro que serão ajustados para a obtenção de um cálculo de média adequado e para tornar o laço de controle de retorno resultante estável o suficiente. Estes dois coeficientes de filtro terão valores dados pelos parâmetros de camada de MAC a seguir:
A = MAC _ Xdrifl _ Fitier A B = MAC _ Xdrifi _ Fiher _ B O comprimento instantâneo do intervalo de tempo de sistema Tslot (n) 'é definido, e esse valor pode ser expresso como a soma do comprimento de intervalo de tempo padrão e um pequeno termo de correção:
<formula>formula see original document page 213</formula>
O valor instantâneo do comprimento de intervalo de tempo é atualizado por:
<formula>formula see original document page 213</formula>
Como é esperado que a correção seja muito pequena, pode-se desprezar o termo de segunda ordem. A versão simplificada é :
<formula>formula see original document page 213</formula>
Na prática, geralmente, apenas o desvio de comprimento de intervalo de tempo precisa ser computado:
<formula>formula see original document page 213</formula>
Isto pode ser expresso como uma função do desvio prévio:
<formula>formula see original document page 213</formula>
De modo a se garantir que a descrição matemática do algoritmo representado pela presente Figura 28 seja bem entendida, o processo inteiro é resumido aqui com um pseudocódigo.
Primeira inicialização
<formula>formula see original document page 213</formula>
Start_Time = primeiro valor de tempo de ressincronização Sum_Clock_Corr = O
Mediante uma recepção de um sinal de orientação ou de qualquer mensagem válida, fazer
Acumular a correção de relógio
Sum Clock Corr = Sum Clock Corr + Clock Correction Atualizar o tempo desde a última estimativa de deriva de relógio
Time_Since_Last_Xdrift_Update = Resync_Time - Start_Time
Se Time_Since_Last_Xdrift_Update < MAC_Xdrift_Tmin
Então esperar pela próxima mensagem
Caso contrário, fazer
Computar a deriva de cristal
Xdrift = Sum_Clock_Corr / Time_Since_Last_Xdrift_Update
Filtrar a estimativa de deriva
Xdrift_filt=A * Xdrift + B * Xdrift_filt
Atualizar a correção de intervalo de tempo
ATslot = ATslot + Xdrift_filt * TS_Length
Inicializar Start_Time para a próxima iteração
Start_Time = último valor de Resync_Time
Inicializar o acumulador de correção de relógio para a próxima iteração
Sum_Clock_Corr = 0
Esperar por uma nova mensagem
Fim
A acurácia requerida para uma compensação própria de deriva de cristal é de em torno de 1 ppm. Isto provavelmente tornará impossível uma correção direta do parâmetro MAC__TS_Length, especialmente se a resolução do SACT não for muito alta. Portanto, é sugerido, no começo de cada intervalo de tempo, recarregar o temporizador de contagem regressiva com o valor de comprimento de intervalo de tempo padrão, MAC_TS_Length. A cada MAC_Xdrif t_LeapTS intervalos de tempo, um "intervalo de tempo de pulo" será introduzido. Isto é explicado com o pseudocódigo a seguir:
<formula>formula see original document page 215</formula>
No código acima, Time_Slot_Number é um número começando a partir de O e incrementado em cada intervalo de tempo, não é o número de intervalo de tempo usado para a identificação da posição em um hiperquadro. Deve ser destacado que para uma compensação ótima de deriva de cristal, o recarregamento de SACT acima deve ser realizado com a acurácia plena provida pelo firmware, conforme especificado pelo parâmetro MAC_FW_Acccuracy. A resolução do algoritmo de correção depende da faixa de intervalo de tempo de pulo, conforme mostrado pela equação a seguir:
<formula>formula see original document page 215</formula>
Compensaçao de correção de deriva de cristal =
<formula>formula see original document page 215</formula>
Uma resolução melhor ou igual a 1 ppm deve ser almejada. Por outro lado, a faixa de intervalo de tempo de pulso deve ser pequena o bastante para se evitarem correções de relógio maiores do que a margem de intervalo de tempo. Ao satisfazer a esse critério, a desigualdade a seguir deve ser respeitada:
<formula>formula see original document page 215</formula>
Parte das vantagens do presente assunto de protocolo é a provisão de um sistema o qual em si é baseado em um sistema de autogerenciamento e otimização de pontos finais que é organizado em células. Cada célula tem um relê de célula o qual serve à finalidade de retransmitir toda a informação para e da rede para uma outra rede de área ampla operando em um protocolo de TCP/IP. Devido a esse fato, a assimilação de um ponto final a uma dada célula não é controlada e pode crescer sem limites. Obviamente, os relês de célula têm limitações de recurso e um crescimento além de certos limites sobrecarregará estes recursos.
O presente aspecto em particular do presente assunto é com base em certos indicadores do tamanho de célula que são comunicados para todos os pontos finais na célula. Os pontos finais que estão se unindo à rede e poderiam ter a possibilidade de se unirem a mais de uma célula usarão esta informação no processo de decisão de a qual célula se unir. Se os indicadores forem que a célula A está cheia ou perto de ficar cheia, a célula B será escolhida pelo presente assunto em questão para sincronização, mesmo se as indicações forem que a célula A pode ser uma célula muito melhor para a transferência (via upload) de tráfego de rede.
Embora as células operem em isolamento devido às seqüências de salto de freqüência quase ortogonais, em raras ocasiões o tráfego pode ser escutado ao acaso de uma célula para a outra para pontos finais localizados nas fronteiras se tocando. Nesses eventos, os indicadores de tamanho de célula podem ser usados para o comando de uma decisão para migração de uma célula cheia para uma célula vazia ou muito menos cheia. Assim sendo, pelo presente assunto discutido de outra forma aqui, com base nesses presentes processos, os tamanhos de célula serão gerenciados e equilibrados ao longo do tempo, permitindo que um autogerenciamento e uma otimização continuem.
Mais particularmente, os presentes aspectos deste assunto são aplicáveis para modalidades configuradas como uma rede de árvore, onde os nós são organizados em células com um concentrador (ou um nó de raiz) na "cabeça" de cada célula. Conforme discutido de outra forma aqui, cada nó tem um nível associado a seu lugar na célula. 0 nó de raiz é de nível 1 e sempre deve ser sincronizado (por definição). De modo a levar seus dados para o nó de raiz, um nó deve ser sincronizado na célula correspondente. O processo de sincronização requer uma checagem manual entre um nó sincronizado e um outro nó. Um nó o qual se sincroniza com um outro se torna seu filho e o outro nó se torna o pai do primeiro. O novo nível de nó é um a mais do que aquele de seu pai. Portanto, todos os nós têm um nível acima de 1. Os nós do mesmo nível são denominados filhos. 0 grupo de pais, irmãos e filhos de um nó é denominado seus vizinhos.
Pelo presente assunto, cada nó mantém uma tabela de seus vizinhos. A informação sobre os vizinhos é usada para várias finalidades (sincronização, roteamento e similares), incluindo a transmissão de pacotes de difusão. Efetivamente, a difusão na realidade é uma mensagem de multidifusão enviada para todos os filhos do nó. Assim, é importante que cada nó esteja na tabela de vizinho de pelo menos um de seus pais, para se garantir a entrega de pacotes de difusão. Isto é um dos papéis da requisição de sincronização: pelo envio de um reconhecimento de sincronização (SYNC_ACK), um pai garante que seu novo filho esteja em sua tabela de vizinho. Pelo presente protocolo, o pai de um nó o qual envio um SYNC_ACK é denominado um SYNC_FATHER deste nó. 0 SYNC_FATHER é o único pai que garante que o nó esteja em sua tabela de vizinho e, assim, o único pai o qual garante que enviará uma difusão para o nó. Um nó sempre deve ter um SYNC_FATHER.
Sempre que a memória de um nó estiver limitada, da mesma forma estará sua tabela de vizinho. O problema técnico surge quando a tabela está cheia e um novo nó requisita uma sincronização. O nó sincronizado com a tabela cheia não poderá reconhecer positivamente a requisição de sincronização do novo nó sem a inserção dele na tabela. Qualquer atividade como essa poderia levar a um nó na célula não recebendo difusões (se ele não estiver na tabela de um outro pai). Infelizmente, se o direito de sincronização for recusado, então, poderia levar a um nó órfão (não em uma célula) não ser capaz de entregar seus dados. Da mesma forma, o nó "pai" não pode criar espaço para o novo nó pela remoção de qualquer um dos direitos nesta tabela (porque fazê-lo poderia fazer com que um nó não recebesse difusões).
A solução obtida pelo presente protocolo de gerenciamento é primariamente com base em duas coisas. Em primeiro lugar, um bit (EPSF significando pai de sync potencial suficiente) é enviado em cada pacote e mantido na tabela de vizinho para cada vizinho. Este bit é regulado para 1 por cada nó, se o número de pai e filhos em sua
tabela de vizinho estiver acima de um dado limite (o qual é escolhido para indicar que eles poderiam enviar com segurança uma requisição para um outro nó). A segunda parte é a mensagem de notificação de fora de tabela (TON) . Com base no bit de EPSF, um nó recebendo uma nova requisição de sincronização enquanto sua tabela de vizinho está cheia, pode decidir remover um de seus filhos, se seu bit de EPSF for um. Mas isto deve indicar para seu filho que ele não mais estará em sua tabela de vizinho. Isso é realizado pelo envio da mensagem de TON para seu filho. Mediante o recebimento desta mensagem, este filho olhará se seu pai era seu SYNC_FATHER. Se este fora o caso, então, ele deve encontrar um outro SYNC_FATHER para garantir que esteja na tabela de vizinho de um de seus pais e, assim, receba difusões.
Esta solução provê uma forma de nunca recusar uma sincronização com um novo nó, enquanto se garante que todos os nós estejam na tabela de vizinho de um de seus pais, e, assim, garantindo que eles recebam pacotes de difusão.
Quando se trata de gerenciamento de vizinhança e informação de vizinhança pelo presente assunto de protocolo, a camada de MAC está encarregada do gerenciamento vis-à-vis de vizinhos. Assim sendo, a cada vez em que um ponto final recebe uma mensagem, ele também salva ou atualiza o parâmetro do remetente em uma lista.
Portanto, pelo presente assunto, apenas parâmetros de vizinho a 1 salto são conhecidos e salvos no ponto final. O relê de célula é o único dispositivo que conhece o status dos pontos finais pertencentes a sua célula, mas é gerenciado com a lista de vizinho na camada de rede.
A camada de MAC não apenas gerenciará sua própria tabela de vizinho, mas também indicará para as camadas superiores (particularmente para a camada de NET, por meio da camada de LLC) algumas das mudanças quando elas ocorrem (por exemplo, inclusão de um novo vizinho).
A tabela de vizinho de MAC contém parâmetros dos vizinhos. Ela é limitada no tamanho pela variável Max_Nb_of_Neighbors. Para cada vizinho, os parâmetros são:
• Address, (Endereço) 4 bytes (o endereço de MAC do vizinho).
• Levei, (Nível) 1 byte (o último nível conhecido do vizinho.O nível é 0 se o vizinho não for sincronizado. O nível 1 é o relê de célula).
• Average RSSI, (RSSI Médio) 1 byte (RSSI é medido durante a recepção e indicado pela camada física. O valor salvo é um valor médio de RSSI por uma janela deslizante com seu vizinho).
• Cell Relay Address, (Endereço de Relê de Célula) 2 bytes (a célula à qual o vizinho pertence).
• Last TS (Time Slot) number, (Número de Último TS (Intervalo de Tempo) 2 bytes (o intervalo de tempo quando a última recepção ocorreu. Com a informação de seqüência de canal, proporciona o último canal).
• Last Reception Time, (Tempo de Última Recepção) 4 bytes (o tempo quando a última recepção ocorreu. A referência deste tempo é livre para a implementação. Contudo, é sugerido que seja o tempo de ativação do nó.).
• Delta SACT, ASACT, 2 bytes (A diferença de SACT entre o EP e seu vizinho. Este valor é renovado a cada vez em que um a mensagem é recebida a partir de seu vizinho. Isto indica o desalinhamento entre os 2 EPs). GPD, 2 bytes (o atraso de propagação médio global entre o vizinho e o relê de célula. Este valor é indicado no cabeçalho de MAC).
• LPD, 1 byte (o atraso de propagação médio local entre o EP e o vizinho).
· Last reception rate update (Última atualização de taxa de recepção) (o último tempo em que a taxa de recepção deste EP foi atualizada).
• Received rate indicator, RXI, 1 byte (Indicador de taxa recebida) (ele prove uma indicação da freqüência com que o painel dianteiro recebe mensagens deste conteúdo. Ele impedirá o ponto final de se sincronizar com um vizinho que dificilmente seja ouvido).
• Sync_Forbidden, 1 bit (um indicador tipo de flag indicando que este ponto final recusou uma sincronização).
• Sync_Father, 1 bit (um indicador tipo de flag indicando que este vizinho permitiu que o ponto final ficasse sincronizado. Apenas um vizinho pode ter este bit regulado. Ele é regulado quando o SYNC ACK é recebido. Quando um ponto final muda seu nível, ele deve limpar todos os indicadores tipo de flag, exceto aqueles atribuídos ao vizinho com que ele recém se sincronizou. Um ponto final deve ter um pai com o bit SYNC Father regulado, de modo a considerar a si mesmo sincronizado).
• Sync_Son, 1 bit (um indicador tipo de flag indicando que o EP permitiu que seu vizinho fosse sincronizado com ele. Este indicador tipo de flag deve ser removido se o nível de seu vizinho mudar). • Registered, 1 bit (Registrado) (um indicador tipo de flag indicando que este vizinho está registrado em uma célula).
• Enough_Potential_Sync_Fathers, 1 bit (um indicador tipo de flag indicando se este vizinho tem um número de irmãos e pais com que ele possa se sincronizar (Sync_Forbidden bit = 0), isto é, é maior do que MAC_Good_Number_of_Potential_Sync_Fathers) .
• Father Acknowledged load, (SAck) 1 byte (carga reconhecida de pai) (número médio de reconhecimentos recebidos por este pai, excluindo-se os reconhecimentos pretendidos para o EP em si. Isto é mantido apenas se o EP for um pai. Isto é usado para estimativa da carga deste pai, a qual, por sua vez, será usada para a determinação da janela de randomização para uma transmissão).
• CSI, 2 bits (o indicador de tamanho de célula deste vizinho).
Devido a limitações de memória, a tabela de vizinho tem um tamanho finito e não pode conter mais de Max_Nb_of_Neighbors entradas. Portanto, é necessário se livrar de algumas entradas conforme elas se tornarem inúteis para a operação da rede.
A tabela de vizinho é gerenciada de acordo com os princípios gerais a seguir:
• Apenas vizinhos que satisfaçam às condições de pai de SYNC potencial serão adicionados à tabela.
• Desde que a tabela não esteja cheia, qualquer novo vizinho que satisfaça às condições de pai de SYNC potencial será adicionado à tabela. • Se a tabela estiver cheia quando um novo pai de SYNC potencial chegar, o novo vizinho tomará o lugar de um menos importante, se um vizinho como esse existir. A importância de um nó na tabela de vizinho é com base no termo de sincronização. Se não houver possibilidade de liberação de algum espaço na tabela, a informação sobre aquele novo vizinho será descartada.
• Nós a partir dos quais nada foi recebido por um longo período de tempo serão considerados como tendo deixado a vizinhança a 1 salto. Se nenhuma mensagem tiver sido recebida a partir de um vizinho por um período de tempo mais longo do que MAC_Neighbor Timeout, o vizinho será removido da tabela de vizinho.
• Se um ponto final for para trás na fase de descoberta, comutar para uma outra célula ou experimentar uma falta de potência, todas as entradas da tabela de vizinho deverão ser apagadas.
O processo de liberação de espaço na tabela pode ser detalhado adicionalmente conforme se segue. Deve ser destacado que este processo não é realizado em uma base em andamento, mas apenas quando um novo pai de SYNC potencial precisar ser inserido em uma tabela a qual já esteja cheia.
• Checar as condições de pai de SYNC potencial. Se algumas entradas não combinarem mais com as condições de pai de SYNC potencial, elas poderão ser apagadas da tabela.
• Os vizinhos mais importantes na tabela são aqueles com o termo de sincronização mais baixo. Se um nó precisar ser retirado, aquele com o termo mais alto deverá ser removido (veja a exceção para o pai de SYNC abaixo). Se um ponto final não for sincronizado, qualquer vizinho que combine com os critérios de pai de SYNC potencial poderá ser adicionado a sua tabela de vizinho. A importância relativa destas entradas será definida de acordo com o termo para a fase de descoberta, SYNC_Disc_Merit.
Se este ponto final estiver em um processo de partida a frio, apenas os vizinhos pertencentes à célula preferida serão permitidos na tabela de vizinho. Se este ponto final estiver em um processo de partida a quente, todos os pais de SYNC potenciais, qualquer que seja a célula a qual pertençam, serão permitidos na tabela.
Se um ponto final for sincronizado, a importância das entradas será com base no termo de sincronização (SYNC_Merit). Se um nó precisar ser retirado, aquele com o SYNC_ Merit mais alto deverá ser removido. Há uma exceção a esta regra: o pai de SYNC não pode ser removido da tabela. Se um pai precisar ser removido quando o pai de SYNC calhar de ter o pior SYNC_Merit, o menos pior a seguir deverá ser removido.
O termo de sincronização depende, dentre outros parâmetros, do indicador de taxa de recepção, RXI. Como os recém-chegados têm um RXI baixo, isto criará uma histerese para a inclusão de novos vizinhos na tabela. Isto limitará o ir e vir na tabela.
No modo sincronizado, os nós de outras células não são introduzidos na tabela. Eles são avaliados dinamicamente para se checar se eles poderiam oferecer um melhor ponto de sincronização.
A presente Figura 3 OA também descreve em formato de fluxograma o presente gerenciamento de tabela de vizinho.
Os pontos finais têm endereços de MAC fixos e podem potencialmente se sincronizar e conectar a qualquer célula.
Contudo, o protocolo deve levar em consideração que algumas células são proibidas. Este pode ser o caso se o usuário / serviço de utilidade pública quiser controlar a partilha de pontos finais em células diferentes, ou meramente se um usuário não quiser compartilhar sua rede com um outro usuário / serviço de utilidade pública (este último caso é manipulado normalmente por se terem diferentes IDs de serviço de utilidade pública no cabeçalho de PHY). De modo a se gerenciar a afiliação de uma célula, um endereço de célula unicamente identifica cada célula.
A partir do ponto de vista de camada de MAC, um nó pode ser sincronizado com qualquer célula. Portanto, é papel da camada de API contar à camada de MAC se uma célula está autorizada ou não. Esta informação então é mantida no nível de camada de MAC, o que não considerará uma célula proibida para sincronização.
Todas as células proibidas são reautorizadas pela camada de MAC, se o ponto final ficar não sincronizado por um período de tempo mais longo do que MAC_Unsynchronized_Timeout.
Em uma partida a frio, uma vez que o nó seja sincronizado, ele informa à camada de API esta sincronização bem sucedida, indicando o endereço de célula correspondente. A camada de API deve informar, então, à camada de MAC quando o ponto final se tornar registrado. A camada de MAC não autorizará outros nós a se sincronizarem com ela, se não estiver registrada. Assim que um nó é registrado, a camada de MAC salvará o endereço de célula e o usará como uma célula preferida, no caso de uma partida a quente.
Em uma partida a quente, o nó procura sua célula preferida. Se ele for bem sucedido em encontrar a célula e se sincronizar com um de seus membros, a camada de MAC considerará a si mesma já registrada (bit de RS = 1) , e imediatamente autorizará as requisições de sincronização de seus vizinhos. A camada de API precisa contar à camada de MAC se esta hipótese estava correta ou não.
A partida a quente acelerará o processo de sincronização de uma célula, após uma falta de potência de grande escala.
Em geral, pelo presente assunto de protocolo, dois tipos de mensagens são reconhecidos: dados de monodifusão contendo LPDU a partir da camada de LLC e requisições de SYNC. Os dados de monodifusão são reconhecidos (ou não) com mensagens de ACK (ou NACK) e requisições de SYNC por mensagens de SYNC ACK (ou SYNC NACK).
ACK, NACK, SYNC ACK e SYNC NACK devem ser enviados na intervalo de tempo da recepção do pacote correspondente. Mais precisamente, o reconhecimento deve ser enviado no último subintervalo de tempo.
Cada mensagem que deve ser reconhecida tem um ID de quadro de MAC (FID), inserido no cabeçalho de MAC. A mensagem de (não) reconhecimento mencionará este ID de quadro em seu próprio cabeçalho de MAC. O ID de quadro de MAC é um contador, incrementado pela camada de MAC em cada envio de dados de monodifusão ou de requisição de SYNC.
Para cada LPDU, o LLC pedido a enviar, a camada de MAC indicará de volta se a mensagem de dados de monodifusão foi reconhecida (ACK), não reconhecida (NACK) ou não reconhecida (nem ACK nem NACK recebidos).
As mensagens de dados de difusão são não reconhecidas. Elas não são endereçadas em qualquer nó em particular e, assim, não contêm um endereço de destino no seu cabeçalho de MAC, ou ID de quadro de MAC. Quando a mensagem de dados de difusão tiver sido enviada, a camada de MAC a notificará para a camada de LLC.
Ainda com referência a reconhecimentos, mais especificamente, os presentes aspectos deste assunto em relação a reconhecimentos de difusão provêem uma funcionalidade usada para a distribuição da mesma informação a partir do nó mestre para todo nó pertencente a uma rede de malha. Um aspecto de uma difusão padrão é que nunca há uma garantia que todo receptor pegou a informação e, mais particularmente em uma rede de malha, a mensagem pode precisar ser encaminhada para todo nó, qualquer que seja seu nível. Para se garantir que todo nó receba os dados, o presente assunto de protocolo inclui uma abordagem algorítmica a qual usa uma difusão reconhecida, cuja abordagem também pode ser vista como uma sucessão de transmissões de multidifusão.
Conceitualmente, será entendido que o presente processo de sincronização resulta em se proporcionar um nível a todo nó na rede. O nível representa o número de saltos entre o nó e o ponto de extração de dados. Cada nó tem um certo número de vizinhos com um nível mais baixo (mais próximo do ponto de extração), denominados pais do nó; nível igual, denominados irmãos; e nível mais alto (além do ponto de extração), denominados filhos. Uma difusão pode ser gerada apenas pelo nó mestre da rede. A difusão deve ser encaminhada pelos nós de receptor para seus próprios filhos.
Uma detecção de duplicação evita que um nó encaminhe a mesma difusão mais de uma vez. A identificação desta duplicação é com base em um ID de difusão gerado pelo nó mestre. A propagação de difusão é reconhecida entre cada salto. Para se poupar tempo quando muitos filhos estão presentes abaixo de um nó, um reconhecimento da difusão é organizado. O nó remetente seleciona seus filhos e adiciona seu endereço de MAC no cabeçalho da mensagem de difusão. Os nós de receptor checam se seu endereço está presente no cabeçalho para aceitarem a difusão. A ordem dos endereços do cabeçalho proporciona ao destinatário uma ordem de reconhecimento. O ponto final o qual tem o primeiro endereço tem que reconhecer no primeiro intervalo que se segue à recepção; o segundo, no segundo intervalo, e assim por diante. Os nós que foram reconhecidos (ou não) são armazenados. A mensagem de difusão é repetida apenas para aqueles que não reconheceram.
Dito de uma outra forma, por aspectos adicionais do presente assunto, quando uma mensagem tem que ser enviada para vários pontos finais (Difusão / Multidifusão, indicado por LLC), a camada de MAC envia duas mensagens sucessivamente (em dois intervalos de tempo). A primeira mensagem, uma lista de Difusão / Multidifusão, contém endereços na próxima mensagem de difusão. A segunda é a mensagem de difusão e contém os dados de difusão, com um ID de difusão no parâmetro. A ordem dos endereços na Mensagem de Lista de Difusão proporciona ao destinatário uma ordem de reconhecimento. O ponto final, o qual tem o primeiro endereço, tem que reconhecer no primeiro subintervalo de tempo do intervalo de tempo que se segue à recepção; o segundo em segundos subintervalos de tempo, e assim por diante. Os pontos finais que reconheceram (ou não) são indicados para a camada de LLC, a qual pode repetir (ou não) a mensagem para aqueles os quais não reconheceram. Se um ponto final recebeu uma mensagem de difusão e deve encaminhá-la, preferencialmente ele será configurado para esperar por tempo suficiente, para deixar os outros pontos finais reconhecerem, de modo a evitar uma interferência.
Essa abordagem prove múltiplos benefícios, tal como uma inundação de transmissão ser controlada; os nós apenas salvam a informação sobre seus filhos, o que resulta em um ganho líquido de memória; uma redundância garante que quase 100% dos nós obtenham os dados; e a velocidade de propagação de dados pela rede é nivelada.
O presente assunto de protocolo vantajosamente usa uma CRC de 32 bits (Verificação de Redundância Cíclica) para evitar uma corrupção de mensagem por ruído ou interferência. A CRC é computada pelo remetente no cabeçalho de MAC inteiro e LPDU e colocada no fim do quadro. No lado de receptor, o valor da CRC é usado para se verificar a validade da mensagem. Se a CRC combinar com a mensagem, o quadro será aceito. Se não combinar, ela é descartada.
A CRC usada é a CRC padrão de 32 bits do IEEE 802.3. A presente Figura 30 prove uma representação esquemática de uma implementação típica de CRC de 32 bits. O polinômio gerador dessa CRC é:
<formula>formula see original document page 230</formula>
A CRC é computada com um registrador de deslocamento de retorno linear inicializado para OxFFFFFFFF (ou qualquer implementação equivalente). A computação começa com o primeiro byte do cabeçalho de MAC e termina com o último byte de LPDU. Cada byte é alimentado no registrador de deslocamento com o bit menos significativo primeiro. Ao fim da divisão polinomial, o registrador de deslocamento contém o resto da divisão. O primeiro byte a ser deslocado para fora deste registrador corresponde ao primeiro byte de redundância. Ele é interpretado pelo bit menos significativo primeiro e deve ser complementado até um antes de ser apensado a LPDU.
Com referência à segurança, o presente assunto de protocolo preferencialmente não provê um serviço de encriptação. Como tal, os datagramas são enviados preferencialmente na interface de ar sem encriptação.
Contudo, isto não quer dizer que o presente assunto de protocolo não é um protocolo seguro. De fato, é um protocolo projetado, a camada física para o que usa uma técnica de FHSS com um padrão de salto de freqüência muito longo. Uma escuta clandestina nesse sistema requereria um esforço de engenharia significativo. Esta segurança intrínseca é adicionalmente melhorada pelo uso de seqüências de Fibonacci para se tornar o padrão de salto diferente em cada célula.
Caso essa abordagem para a segurança seja considerada insuficiente para algumas aplicações críticas, está no escopo do presente assunto suplementar essa segurança pela encriptação dos dados de usuário nas camadas de aplicativo.
Certos aspectos vantajosos do presente assunto se referem ao que pode ser considerado geralmente como regulagem de tráfego de rede, ou, mais especificamente, como controle de carga de tráfego de rede. Em particular, são providos procedimentos para se evitarem condições segundo as quais a carga de tráfego cresce acima de um ponto de paralisia total em uma rede de malha Aloha com intervalo. Em certos aspectos, os presentes procedimentos usam a monitoração de reconhecimentos recebidos para avaliação da densidade de tráfego. Pelo menos vários benefícios identificáveis dessas presentes metodologias são que ela permite que o tráfego de enlace ascendente em uma rede de malha flua em condições ótimas e evita uma paralisia total de tráfego devido a uma operação da rede além de seu limite.
Pelo presente assunto, um controle de carga de tráfego é usado para limitação do tráfego de modo a se evitar usar o canal além de sua densidade de tráfego ótima. Isto é necessário porque o presente assunto de protocolo opera como um sistema Aloha com intervalo, e para um sistema como esse, uma densidade de tráfego acima de um dado limite pode aumentar a taxa de colisão para um nível inaceitável e bloquear completamente o fluxo de dados (isto é, o fluxo de dados se torna paralisado). O presente controle de tráfego preferencialmente é usado apenas para uma transferência (via upload) de tráfego, a partir dos pontos finais para o relê de célula (ou mestre de célula).
Mais particularmente, o presente assunto de controle de carga de tráfego é aplicável geralmente a qualquer rede de malha com um nó atuando como um ponto de extração de dados. 0 tráfego de dados a partir dos nós individuais até este ponto de extração é considerado como um tráfego de enlace ascendente. Conforme esse tráfego de enlace ascendente gerado na rede cresce mais alto, colisões internas entre pacotes ocorrerão. Em algum ponto, essas colisões serão freqüentes o bastante para degradarem o ritmo de transferência efetivo do sistema. A relação entre probabilidade de colisão e ritmo de transferência efetivo é bem conhecida com a teoria de Aloha com intervalo. A teoria clássica lida com o caso em que nenhum agente de emperramento externo está presente. Aqui, a situação é mais difícil de se analisar, porque há ambos os tipos de colisão ao mesmo tempo, isto é, colisões internas devido ao tráfego interno e colisões externas com os outros usuários da banda.
Assim sendo, o presente assunto vantajosamente introduz um mecanismo de controle para desaceleração do tráfego de dados conforme ele crescer acima de um dado limite. Os nós precisam ser capazes de temporariamente manterem transmissões e armazenarem mensagens em um buffer, quando eles detectarem que o canal está ocupado demais.
Este controle de carga de tráfego impedirá os nós de usarem o canal além de sua densidade de tráfego ótima. Se isto não for feito, a densidade de tráfego poderá aumentar a taxa de colisão para um nível inaceitável, que não apenas diminuiria a performance, mas que poderia bloquear completamente o fluxo de dados.
Portanto, pelo presente assunto, de modo a controlar apropriadamente a carga de tráfego, um ponto final precisa avaliar a quantidade de tráfego indo através da rede. Para as presentes finalidades de descrição, um primeiro nó no alcance de rede de um segundo nó e na direção do ponto de extração para o segundo nó será denominado um nó pai em relação a esse segundo nó. A presente Figura 31 é uma representação esquemática do presente assunto de monitoração de carga de tráfego, onde um dado nó B está ouvindo mensagens de (N)ACK a partir de seus pais A e C. Para as finalidades de controle de carga de tráfego mencionadas acima, um ponto final de exemplo (nó B na Figura 31 de exemplo) gravará os reconhecimentos transmitidos por seus pais A e C e não pretendidos para si mesmo. Esses reconhecimentos proporcionarão informação suficiente para se avaliar a carga de tráfego, porque, no presente protocolo, um nó tem que reconhecer todos os pacotes de dados que ele recebe. Esta abordagem é consistente com o fato que o gerenciamento de tráfego será usado principalmente pelos pontos finais se comunicando diretamente co um relê de célula, a partir do que apenas reconhecimentos são transmitidos em uma situação de transferência (via upload). Contudo, essa informação, não obstante, não é suficiente, porque um nó precisa ser capaz de distinguir entre uma situação de tráfego baixo que gera poucos reconhecimentos e uma situação de tráfego muito alto que também gera poucos reconhecimentos, porque a maior parte dos pacotes é perdida devido a colisões. Para esta finalidade, preferencialmente cada nó gravará todas as tentativas de comunicação com os nós pais e computará uma taxa de sucesso de comunicação média. Combinando-se a taxa de reconhecimentos ouvidos ao acaso e a taxa de sucesso de combinação, um nó será capaz de estimar a densidade de tráfego de uma forma não ambígua.
De uma forma formal, pode-se definir a densidade de entrada de tráfego Ra como o número médio de pacotes de dados chegando ao nó A (Figura 31) em um intervalo de tempo. Este conceito é útil para se medir quão ocupado está o nó A. Também é conhecido a partir da teoria de Aloha com intervalo que a densidade de entrada de tráfego tem um valor ótimo. Se a densidade de entrada de tráfego crescer acima daquele valor ótimo, o ritmo de transferência cai devido a colisões. Todos os pacotes de dados chegando ao nó A são considerados na definição de densidade de entrada de tráfego, independentemente de eles serem ou não recebidos de forma bem sucedida. Contudo, por razões práticas, os pacotes emanando do nó B preferencialmente são excluídos (uma vez que o foco atualmente está em se tentar derivar uma regra de comportamento para esse nó B) . Também é definido o número médio de reconhecimentos emanando a partir do nó A e ouvidos ao acaso pelo nó B (excluindo-se aqueles pretendidos para o Nó B) em um intervalo de tempo, SA. A taxa de sucesso de comunicação do nó B para o nó A é denominada CSrba e Qb é definida como a probabilidade de o nó B estar em um estado de escuta. A partir da teoria de probabilidade elementar, pode ser mostrado que a estimativa para a densidade de entrada de tráfego no nó A é dada pelo seguinte:
<formula>formula see original document page 234</formula> Para se evitar estourar para cima um nó com pacotes além da densidade de entrada de tráfego ótima, a taxa de transmissão de pacotes é limitada pelo presente assunto.
Para isto, é definida a densidade de entrada de tráfego máxima RMAx· A partir da teoria de Aloha com intervalo, isto deve ser igual a um, mas para ser conservador no projeto, é preferível usar um valor menor. A densidade de entrada de tráfego total no nó A é a soma da densidade tráfego estimada Ra e do tráfego que o nó B gerará para o nó A. O nó B modulará o tráfego que ele gera para o nó A, de modo a se evitar que a densidade de entrada de tráfego total no nó A exceda ao valor máximo admitido Rmax.
Uma forma direta pelo presente assunto para a implementação desta limitação é enviar as mensagens em um tempo randômico em uma janela de randomização de comprimento Tw. O comprimento da janela de randomização deve respeitar a condição a seguir,
<formula>formula see original document page 235</formula>
onde Tw é expresso em unidades de intervalo de tempo.
Pelo presente assunto, se um nó tiver vários pais, preferencialmente ele deve dimensionar o comprimento de sua janela de randomização de acordo com o pai com a densidade de entrada de tráfego mais alta, mesmo se o pacote não for pretendido para este pai.
As tarefas a seguir preferencialmente são realizadas em todo nó na rede. Elas são para a monitoração de todos os reconhecimentos ouvidos a acaso a partir dos nós pais; para a gravação de todos os sucessos / as falhas de comunicação com todo nó pai; para manutenção de um registro do tempo gasto no estado de transmissão ou de escuta; para a computação da taxa de sucesso CSR e para a computação da densidade de entrada de tráfego estimada, R; e para desaceleração da repulsão de transmissões se a densidade de entrada de tráfego para o pai mais ocupado se tornar grande demais.
Todas essas variáveis médias (densidade de tráfego de entrada, taxa de reconhecimentos escutados ao acaso, taxa de sucesso de comunicação e probabilidade de um nó estar escutando) podem ser computadas com um algoritmo de média deslizante para evitação do uso de memória em excesso de microprocessador.
Com referência a esse assunto em termos um pouco diferentes, pelo presente assunto, uma densidade de entrada de tráfego máxima definida pode ser referida como MAC_Traffic_Density_max, de modo que a densidade de entrada de tráfego total no ponto final A, agora incluindo o tráfego de B para A seja dada por:
<formula>formula see original document page 236</formula>
onde Tx_Níndow é o comprimento em intervalos de tempo da janela de randomização usada para a transmissão de um pacote. O pacote de dados será transmitido em um intervalo de tempo escolhida randomicamente nesta janela de randomização. Segue-se uma equação para a computação do comprimento desta janela como uma função de transmissões parâmetros prontamente medidos:
<formula>formula see original document page 236</formula>
MAC_Traffic_Densiry_max - Ra com
<formula>formula see original document page 237</formula>
onde LPDba é o atraso de propagação local de B para A, Qb é a probabilidade de o ponto final B estar no estado de recepção e SaCkA é o número médio de reconhecimentos transmitidos por A e recebidos por B por intervalo de tempo. Para as finalidades práticas, o comprimento de Tx_Window precisa ser delimitado. 0 resultado deste cálculo será truncado de modo a sempre estar na faixa a seguir:
<formula>formula see original document page 237</formula>
O comprimento de janela de randomização então será computado com o seguinte:
<formula>formula see original document page 237</formula>
onde é usado MAC_Traffic_Density_max. O ponto final tem que monitorar o tráfego para cada um de seus pais, de modo a se ter um valor atualizado de SackA- Ao final de cada intervalo de tempo, o ponto final computa novos valores dos parâmetros Sackft em sua tabela de vizinhos. Isto tem que ser feito sistematicamente, .independentemente de um pacote daquele vizinho ter ou não sido recebido. Nós usamos para isto uma janela de média deslizante conforme definido abaixo:
<formula>formula see original document page 237</formula>
Nessa fórmula, η se refere ao número de intervalo de tempo e Ntmw é o número de intervalos de tempo na janela de monitoração de tráfego. Este número é dado pelo parâmetro de camada de MAC N™w MAC^Traffic Momtoting Window _ Qb também é atualizado em cada intervalo de tempo com o seguinte:
<formula>formula see original document page 238</formula>
Obviamente, se um ponto final tiver vários pais, ele sempre deve dimensionar o comprimento de sua janela de randomização de acordo com o pai com a densidade de entrada de tráfego mais alta, mesmo se o pacote não for pretendido para este pai.
Devido ao custo de hardware, o tamanho de memória para se pouparem mensagens não será ilimitado do ponto de vista de um sistema. Os pacotes durante seu curso entre um ponto final e um mestre de célula são armazenados como em buffer em nós. Para se evitar ficar diante de situações de tráfego bloqueado sem solução, quando a memória está cheia, o armazenamento de pacotes deve seguir algumas recomendações importantes.
O armazenamento de pacotes deve ser dividido em duas categorias:
• Pacotes indo em enlace ascendente: enlace ascendente, enlace rompido, notificação de falta...
• Pacotes indo em enlace descendente: enlace descendente, difusão...
O número de pacotes pertencentes a cada categoria deve ser monitorado ao longo do tempo e é chamado nb_of_uplink_buffered_packets e nb_of_downlink_buffered_packets. Há um número máximo de pacotes que podem ser salvos para cada categoria.
nb_of_uplink_buffered_packets < MAC_Max_nb_o f_up1ink_bu f f e red_pac ket s nb_of_downlink_buffered_packets < MAC_Max_nb_of_downlink_buffered_packets nb_of_uplink_buffered_packets + nb_of_downlink_buffered_packets < memory size
Para se manter esta informação, é necessário que camadas diferentes indiquem a categoria do pacote que elas enviam / recebem. Como o mestre de célula apenas recebe um tráfego de enlace ascendente e envia um tráfego de enlace descendente, estas categorias podem ser respectivamente comparadas com pacotes armazenados em buffer chegando e saindo.
Uma vez que um buffer de qualquer tipo esteja cheio, se uma mensagem do tipo correspondente for recebida, a camada de MAC deverá responder ao remetente com uma mensagem NACK e descartar o pacote, já que não há lugar para salvá-lo.
Para o caso do mestre de célula, se a conectividade de WAN for boa, o buffer de enlace ascendente (entrando) nunca deve estar cheio. De fato, o ritmo de transferência da WAN é altamente superior àquele da Linknet. Se o buffer de enlace ascendente calhar de estar cheio, o mesmo algoritmo será usado e o mestre de célula começará a enviar NACK para os pacotes chegando. Esta situação em contrapartida degradará altamente as performances da rede e poderá criar instabilidade de rede e perdas de pacote.
Com respeito a pontos de discussão a seguir sobre a presente programação de mensagens, deve ser entendido que, neste contexto, uma mensagem se refere a qualquer outro pacote além de um reconhecimento. Quando a camada de aplicativo a requisita, ou quando há uma mensagem recebida a encaminhar, uma camada de NET determina o(s) endereço(s) de destino. A camada de LLC lida com a fragmentação e a retransmissão de mensagens. Estas duas camadas enviam requisições para a camada de MAC que adiciona o cabeçalho de MAC aos pacotes e os envia para a camada física para transmissão.
Dentre estas camadas, a MAC está encarregada de programar em qual intervalo de tempo a mensagem será enviada. 0 objetivo principal desta programação é randomizar no tempo as transmissões, de modo a se evitarem colisões com pacotes de vizinhos.
A camada de MAC não apenas deve programar as mensagens de dados vindo das camadas superiores, mas também seus próprios pacotes (reconhecimentos, requisições e sinais de orientação).
As mensagens podem aceitar algum atraso na sua transmissão, enquanto reconhecimentos devem ser enviados no intervalo de tempo da recepção. Estas restrições e a necessidade de randomização no tempo são a base para o processo de programação de pacotes.
Com referência às presentes prioridades para mensagens, a presente Figura 32 é uma tabela que mostra uma lista de prioridade de mensagem de exemplo de acordo com o presente assunto de protocolo. Em geral, há dois tipos principais de pacotes que a camada de MAC deve programar: aqueles vindo das camadas superiores (LPDU) e aqueles gerados pela camada de MAC. A primeira categoria pode ser dividida em dois tipos, dados e notificação de falta de energia, enquanto a segunda categoria inclui requisições e sincronização (SYNC RQST) e reconhecimentos (SYNC ACK ou SYNC NACK), reconhecimento de outras mensagens (ACK ou NACK) , sinais de orientação, requisições de sinal de orientação e sinais de orientação de descoberta. As mensagens de dados podem ter um cabeçalho de MAC diferente, dependendo de sua natureza (monodifusão, difusão, ITP de difusão. . .) , mas todas elas serão tratadas da mesma forma de um ponto de vista de programação.
Algumas mensagens devem ser enviadas com prioridade; dentre todas estas mensagens, os reconhecimentos são os mais importantes. Um (N)ACK deve ser enviado na intervalo de tempo em que ocorreu a recepção da mensagem de monodifusão correspondente; da mesma forma, o SYNC (N)ACK deve ser enviado no mesmo intervalo de tempo que a SYNC RQST correspondente.
0 MAC normalmente não deve enviar mais de uma mensagem em um dado intervalo de tempo, exceto vários sinais de orientação forçados, se o hardware puder lidar com isso. No caso raro em que um EP precisasse reconhecer mais de uma mensagem ou requisições de sincronização no mesmo intervalo de tempo, então, uma deveria ser enviada e a outra cancelada. A razão para isto é que o EP que transmitiu a mensagem ou requisição inicial espera um reconhecimento neste intervalo de tempo e considera a transmissão uma falha após isso (assim, é inútil transmitir um (N)ACK ou SYNC (N)ACK após o intervalo de tempo atual). Embora outros pacotes além de reconhecimentos sejam inicialmente randomizados em uma janela, eles não estão absolutamente restritos a isso e podem ser postergados.
As requisições estão em seguida na lista de prioridade, com a SYNC RQST imediatamente antes de RQST_Beacon.
Todos estes pacotes são necessários para a rede funcionar apropriadamente e, assim, são de prioridade mais alta do que os dados a transportar. Os dados estão em seguida nesta lista de prioridade, seguidos pelos sinais de orientação (em um canal forçado ou não). Estes sinais de orientação são na realidade cabeçalhos de MAC usados para se dar uma informação de sincronização. Uma vez que a mesma informação está em todos os cabeçalhos de MAC, se qualquer mensagem for transmitida na janela em que um sinal de orientação não forçado é requisitado, este sinal de orientação não precisa ser transmitido. Concernente aos sinais de orientação forçados, os quais são disparados pela recepção de um sinal de orientação, eles precisam ser enviados na janela de escuta correspondente, mas apenas se houver um intervalo de tempo disponível: incluindo um novo nó para a rede não deve perturbar os nós já sincronizados.
Há duas exceções que suplantam a ordem de prioridade definida acima: a primeira é quando um EP experimenta uma falta de potência, e a camada de API o notifica para a camada de NET. Esta requisição muda o modo de recepção normal para um modo de economia de potência passivo interrompido pela transmissão de notificações de falta curta. Se um outro EP receber uma destas notificações, ele a retransmitirá com uma ordem de prioridade de dados normais. 0 segundo caso é durante a fase de descoberta, onde sua ordem é sem significado, uma vez que o MAC apenas transmite sinais de orientação de descoberta ou escuta sinais de orientação "forçados".
A programação de uma mensagem consiste em decidir em qual intervalo de tempo ela será transmitida. Há várias restrições que se aplicam a esta tarefa. Em primeiro lugar, devem ser seguidas as regras de prioridade descritas na seção prévia; esta prioridade é aplicada quando duas mensagens devem ser enviadas no mesmo intervalo de tempo. Regras adicionais são necessárias para a definição desta tarefa de programação.
Conforme dito anteriormente, os reconhecimentos são da prioridade mais alta e também devem ser enviados no mesmo intervalo de tempo que a mensagem ou requisição de sincronização que os disparou. Os reconhecimentos não podem ser empurrados no tempo como o podem as mensagens (toda mensagem pode ser postergada, exceto os sinais de orientação forçados, os quais também têm uma janela definida, mas são de prioridade mais baixa e podem ser cancelados, para se dar lugar a qualquer outro pacote, se necessário).
Como resultado desta primeira regra, se uma mensagem fora programada no mesmo intervalo de tempo que a recepção de dados de monodifusão, então, esta mensagem será empurrada por 1 intervalo de tempo, para se permitir que a camada de MAC reconheça o pacote recebido. Apenas reconhecimentos podem ser enviados em um intervalo de tempo quando um pacote de LPDU foi recebido.
De modo a não sobrecarregar a rede, qualquer LPDU e SYNC RQST devem ser randomizados no tempo. A randomização de SYNC RQST é feita na camada de MAC e é discutida em uma outra seção.
A cada vez em que um pacote é recebido a partir da camada de LLC, a camada de MAC o adiciona em um FIFO dedicado a mensagens de dados. Se nenhum pacote de dados estiver sendo enviado, a camada de MAC checará se há uma mensagem neste FIFO. Se este for o caso, então, a janela de transmissão será atualizada (veja a seção de controle de carga de tráfego) e um temporizador de contagem regressiva é determinado randomicamente. Este temporizador é decrementado a cada começo de intervalo de tempo e, quando atinge zero, a mensagem é enviada durante o intervalo de tempo.
Há várias exceções a esta regra. Se uma mensagem de prioridade mais alta já estiver programada ou um reconhecimento for esperado, então, a mensagem será deixada no FIFO e o temporizador de contagem regressiva regulado para expirar pelo próximo intervalo de tempo. Ao contrário, se um sinal de orientação forçado foi programado no mesmo intervalo de tempo, a mensagem de dados é programada (e/ou no próximo para um pacote de monodifusão), então, o sinal de orientação forçado é cancelado.
O sinal de orientação forçado deve ser enviado na janela de escuta do ponto final em uma fase de descoberta. Deve ser randomizado nesta janela. Se o intervalo de tempo já tiver sido tomado, então, o próximo intervalo de tempo deverá ser testado quanto à disponibilidade, fazendo um ciclo até o começo da janela de escuta, se o fim for atingido. Este procedimento deve continuar até um espaço ser encontrado para a transmissão do sinal de orientação forçado ou o ponto final perceber que todos os intervalos de tempo já estão ocupador, era cujo caso ele deve cancelar o sinal de orientação forçado.
Quando um pacote já programado é empurrado no tempo para deixar espaço para um reconhecimento, então, todos os pacotes programados mais tarde serão empurrados pela mesma quantidade de intervalo de tempo. Isto deve concernir apenas a SYNC RQST e Beacon RQST, uma vez que pacotes de dados ficam no FIFO até o intervalo de tempo em que eles são enviados (em cujo ponto já foi determinado que nenhum reconhecimento era esperado).
Finalmente, há várias regras concernentes à transmissão dentro de um dado intervalo de tempo. As mensagens de dados sempre são enviadas no começo do primeiro subintervalo de tempo; isto maximiza o espaço disponível para dados e permite que os pontos finais enviem seus reconhecimentos no último subintervalo de tempo.
Os reconhecimentos de sincronização também devem ser enviados no mesmo intervalo de tempo que a requisição; a SYNC RQST deve ser enviada no segundo subintervalo de tempo e o reconhecimento correspondente no último subintervalo de tempo, independentemente de a resposta ser negativa ou positiva. Se a SYNC RQST disparar um RQST Beacon para checar a conexão com um pai, então, ela também deverá ser enviada no último subintervalo de tempo (onde o SYNC (N)ACK seria enviado se o pai fosse bom).
Os sinais de orientação devem ser randomizados entre o segundo e o quinto subintervalo de tempo para não interferirem com o começo de mensagens de dados ou reconhecimentos. A mesma regra deve se aplicar ao pacote de falta de MAC. Em outras presentes versões do protocolo, os reconhecimentos são feitos no intervalo de tempo seguindo- se à mensagem ou à requisição, o que significa que os pacotes de dados poderiam não ser enviados em intervalos de tempo sucessivos. A presente versão não tem esta restrição, mas é compatível com o fato de não enviar dados traseira com traseira, se o hardware não puder lidar com isso. Os reconhecimentos foram colocados no mesmo intervalo de tempo para estarem na mesma freqüência que os pacotes originais e não ganhar tempo. Resumido para a presente versão:
• (N)ACK deve ser enviado no mesmo intervalo de tempo em que a recepção de uma mensagem de monodifusão ocorreu.
• SYNC (N)ACK deve ser enviado no mesmo intervalo de tempo em que a recepção de SYNC RQST ocorreu.
• (N) ACK, SYNC (N)ACK e RQST Beacon são enviados no último subintervalo de tempo.
• Sinais de orientação são randomizados entre o 2° e o 5° subintervalo de tempo.
• Se o pacote for empurrado por um intervalo de tempo, então, todos os pacotes já programados serão empurrados.
A presente discussão se refere, mais particularmente, a vários aspectos de sistema de notificação de falta do presente assunto. Especificamente, é notado que os pontos finais que experimentam uma falta de potência possuem uma informação importante, que poderia ser retransmitida para o sistema de coleta de dados, podem ser aplicados para finalidades muito úteis de gerenciamento de rede. Contudo, durante uma falta de potência, o suprimento de energia foi cortado. Para dispositivos de baixo custo, os quais não contêm dispositivos de armazenamento de energia, isto significa que eles têm energia limitada disponível e não serão capazes de continuarem a participar na rede. O problema então surge quanto a como mover esta informação valiosa para o relê de célula sob estas circunstâncias.
A presente solução é baseada vantajosamente no uso para a retransmissão da informação dos pontos finais que não experimentem uma falta de potência. Em cada queda de potência, haverá uma franja de autodef inição de onde os pontos finais na zona de queda de potência serão capazes de se comunicarem com pontos finais que ainda estejam tendo potência.
Os pontos finais que experimentam a falta de potência entrarão em um modo de queda de potência uma vez que uma falha de potência seja detectada. Isso imediatamente cessará a operação normal da rede e iniciará umas poucas mensagens de queda de potência curtas por uma janela de. tempo randomizada para se evitarem colisões. Como ainda é capaz de manter um tempo de forma acurada devido a uma compensação de deriva de oscilador, será capaz de selecionar canais de freqüência corretos e tempo para garantir que os pontos finais com potência no alcance sejam capazes de capturarem estas mensagens. Uma vez que os pontos finais com potência capturem a mensagem de falta de potência, eles serão capazes de armazenarem esta informação e enviá-la usando o protocolo de rede normal.
Se a conectividade de rede tiver sido influenciada pela fala de potência, os pontos finais usarão as funções de autogerenciamento de rede normais para o restabelecimento da conectividade, se possível. Uma informação de queda de potência é armazenada durante este tempo e não é perdida. Se a zona de falta de potência for grande apenas uma percentagem das mensagens de queda de potência será reportada, mas deve ser suficiente para se inferirem problemas de falta verdadeiros com uma correlação com uma informação de rede de eletricidade, pelo menos a partir da perspectiva de finalidades de gerenciamento de rede.
Mais particularmente, pelo presente assunto, quando uma falta de potência ocorre, a camada de MAC entra em um modo espacial (requisitado por API). A camada de MAC pára de ouvir e envia 3 mensagens muito curtas com a energia remanescente do EP. Cada uma dessas mensagens é randomizada (mas ainda alinhada com os intervalos de tempo) em uma janela de 5 s. Estas mensagens de falta são processadas por todo mundo que puder ouvi-las. Estas mensagens também são numeradas com um número de falta (1 incremento por falta., não por mensagens enviadas). Se antes de a primeira mensagem de falta ser enviada o EP recuperar sua potência, ele então cancelará as notificações de falta (mas a camada de API é livre para enviar uma mensagem de recuperação de potência) . Mas, se a potência voltar após a primeira mensagem de falta ser enviada, então, o EP enviará as duas remanescentes.
Quando um vizinho que ainda tem potência ouve uma mensagem de falta, sua camada de MAC indica para a camada de NET (através de LLC) a notificação de falta, o endereço de vizinho, o número de falta e o tempo quando a mensagem de falta chegou. Será tarefa da camada de NET encaminhar esta informação para o relê de célula da mesma forma que foi usada para mensagens de enlace ascendente regulares (ou clássicas).
O presente assunto de protocolo assegura de forma benéfica uma análise de outros aspectos da performance relacionada à rede. Especificamente, uma ferramenta de avaliação ambiental de RF embutida é provida para a calibração das necessidades de performance de transceptores de RF. Em particular, uma ferramenta de análise de ambiente de rádio estatística é embutida nos nós de uma rede de uma em questão para fins de provisão de recomendações para o melhoramento do hardware.
O presente sistema é pretendido para uso em bandas de ISM. Estas bandas usualmente caracterizam um nível muito alto de interferência não controlada. As especificações do hardware de RF, bem como a performance esperada da rede dependem fortemente do ambiente eletromagnético nestas bandas. Dois aspectos deste ambiente precisam ser considerados. O primeiro é a perda de percurso ou condições de ponta de perfuração distai. Embora uma grande quantidade de informação esteja disponível sobre este tópico para bandas de ISM, nenhum dado estatístico confiável está disponível para a situação específica de medidor de eletricidade para medidor de eletricidade relevante para esta rede. O segundo aspecto do problema é o nível de interferência. O conhecimento deste parâmetro é muito importante, porque a maior parte do custo de um transceptor de RF está associada a interferências e como combatê-las de forma eficiente. O presente assunto provê a implementação de uma ferramenta de análise de ambiente embutida no protocolo. Isto é uma ferramenta potencialmente valiosa para diagnóstico de rede e planejamento. Também será o ponto de partida para uma definição de hardware de próxima geração para qualquer sistema, porque proverá um meio para suporte de qualquer redução de custo do hardware de RF, pela provisão de um backup de análise de ambiente extensivo para garantir que qualquer novo hardware resultante tenha as especificações requeridas para funcionar neste ambiente. Para essas finalidades, os nós da rede sondarão o ambiente eletromagnético com a função de RSSI (indicador de intensidade de sinal recebido) do receptor. Devido à natureza continuamente mutável deste ambiente, é necessário que um grande número de medições de RSSI seja válido de um ponto de vista estatístico. Portanto, para se evitar confundir a largura de banda limitada com todas essas medições, um processamento de dados estatístico será plicado no nó. Desta forma, apenas uma informação significativa terá que ser reportada para o aplicativo. Dois tipos diferentes de análise de ambiente são especificados neste protocolo. O primeiro é usado para exploração das características de tempo da interferência e é uma medida da função densidade de probabilidade de RSSI. O primeiro tipo de análise ajudará a responder a perguntas como: qual é o comprimento de pacote ótimo para se evitarem colisões com os outros usuários da banda? A segunda análise ajudará a responder a perguntas como: qual é a rejeição de canal adjacente necessária para se evitarem colisões? Qual é a probabilidade de uma colisão ocorrer se dois nós estiverem a alguma distância um do outro?
Um benefício principal é que ela permite a otimização do hardware de RF que precisa funcionar em condições específicas, para a prática do presente assunto em um ambiente de campo em particular.
Considerando-se essas presentes ferramentas de análise ambiental em maiores detalhes, será entendido que as especificações do hardware de RF, bem como a performance esperada da rede, dependem fortemente do ambiente eletromagnético. Dois aspectos deste ambiente precisam ser considerados. O primeiro aspecto é a perda de percurso ou condições de propagação. O segundo aspecto do problema é o nível de interferência. A camada de MAC pode sondar o ambiente eletromagnético com a função de RSSI do receptor, e obter uin número relativamente grande de medições de RSSI para validez estatística. Dois tipos diferentes de análise ambiental são especificados neste protocolo. O primeiro é usado para exploração das características de tempo da interferência e usa a função de autocorrelação de RSSI. O segundo se concentra na intensidade da interferência e usa a função densidade de probabilidade de RSSI.
Com respeito à funcionalidade de análise ambiental em questão, o objetivo do Modo de Aquisição de Autocorrelação de RSSI é medir o RSSI médio e sua função de autocorrelação em um canal único. Neste modo, o ponto final interromperá por algum tempo sua seqüência de salto normal e suas tarefas de comunicação usuais. A camada de MAC configurará seu receptor em um modo de recepção contínuo e requisitará leituras de RSSI a partir da camada PHY a uma taxa dada pelo parâmetro de camada de MAC RSSI_Sampling_Rate. Estas leituras então serão processadas para a extração do valor médio e da função de autocorrelação. A camada de LLC envia a requisição para a camada de MAC com dois argumentos de entrada: o número de canal em que realizar a análise e um número máximo de amostras usadas para a terminação da análise de ambiente.
O RSSI médio, RSSI_avg, será computado de forma iterativa, conforme explicado pelo algoritmo a seguir:
<formula>formula see original document page 252</formula>
Onde nós usamos as definições a seguir:
<formula>formula see original document page 252</formula>
Para a computação da função de autocorrelação, é necessário armazenar na memória os 100 últimos valores do RSSI. A função de autocorrelação será avaliada apenas para um conjunto restrito de valores de atraso. Este conjunto de valores é:
<formula>formula see original document page 252</formula>
Estes valores correspondem aos atrasos de tempo:
<formula>formula see original document page 252</formula>
Em cada leitura de RSSI, o RSSI de média calculado é primeiramente atualizado e, então, os valores de função de autocorrelação são atualizados. O processo de atualização para os valores de função de autocorrelação de RSSI, AF_RSSI(m,η), é:
<formula>formula see original document page 253</formula>
onde nós usamos as definições a seguir:
RSSI (n)= a leitura atual de RSSI
RSSI _ avg (n)~ o novo valor de RSSI_avg
AF _ RSSl (m,n) - o novo valor da função de autocorrelação de RSSI para um atraso m
AF _ RSSI (m,n-\)= o valor antigo da função de autocorrelação de RSSI para um atraso m
Quando o número requisitado de leituras de RSSI é atingido, o processo de aquisição e de atualização pára. O valor RSSI_avg e os valores de AF_RSSI(m) para cada atraso m então são reportados para a camada de LLC na mensagem de confirmação. Este relatório então será encaminhado para a camada NET e para a API, o que a enviará para o relê de célula. A estrutura dos argumentos de saída para a confirmação é mostrada abaixo:
RSSIavg A F_RSS1(0) AFRSSI(I) AF„RSSI{90) A F_RSS1( 100) |
RSSI_avg é um campo de 1 byte e os AF_RSSI (m) são campos de 2 bytes. Após esta análise de ambiente, a camada de MAC ressincroniza seus intervalos de tempo e retoma suas atividades prévias de comunicação.
Pelo presente assunto, deve ser notado também que este processo de análise de ambiente deve ser curto o bastante para se evitar que o ponto final perca sua sincronização com a rede de malha. Mais ainda, o modo de aquisição de autocorrelação deve ser usado preferencialmente em nós não próximos demais do relê de célula de modo a se evitar uma perturbação no fluxo de dados através da rede.
Com respeito à funcionalidade de análise ambiental em questão, o objetivo do modo de aquisição de PDF de RSSI é para medir a função densidade de probabilidade (PDF) das leituras de RSSI em três canais selecionados. Neste modo, o ponto final fica saltando seu número de canal de acordo com a seqüência de salto de célula, como no modo normal. 0 nó continua com todas as suas tarefas de comunicação usuais e usa seu tempo livre para sondar o ambiente.
Três canais diferentes são projetados para a aquisição de PDF de RSSI e eles fazem parte da seqüência de salto básica. A camada de LLC envia a requisição para a camada de MAC com quatro argumentos de entrada: os três números de canal para análise e um valor de contador máximo (RSSI_PDF_Max_Count) usado para a terminação da análise ambiente. 0 procedimento de aquisição de PDF de RSSI é descrito adicionalmente aqui, e a presente Figura 33 provê ilustrações de representação concernentes ao assunto em questão.
Sempre que o receptor saltar para um dos canais selecionados para medição de RSSI, ele requisitará uma leitura da camada PHY. Apenas uma leitura de RSSI é requisitada por intervalo de tempo. Este valor de RSSI então será usado para a atualização da PDF de RSSI para aquele canal. A PDF é um arranjo de 24 intervalos (bins), cada um destes intervalos (bins) correspondendo a uma faixa de RSSI de 3 dB, conforme mostrado na presente Figura 33. Um contador está associado a cada intervalo (bin). Por exemplo, se a leitura de RSSI for igual a -113 dBm, o contador associado ao intervalo (bin) 2 será incrementado. De uma forma geral:
Initialize alibin_k_counters to zero
RSSI_min = -118 dBm
RSSI_step = 3 dB
If RSSI_min + (k-1)*RSSI_step <= RSSI < RSSI_min + k*RSSI_step then
bin_k_counter = bin_k _counter + 1 if bin_k_counter = RSSI_PDF_Max_Count then exit acquisition process
end end
onde bin_k_counter é o contador associado ao intervalo (bin) k.
Há algumas exceções a esta regra. Se o valor de RSSI estiver acima do limite superior do último intervalo (bin), o contador associado ao último intervalo (bin) será incrementado. De uma forma similar, se o valor de RSSI estiver abaixo do limite inferior do primeiro intervalo (bin), o contador associado ao primeiro intervalo (bin) deverá ser incrementado. Se um começo de um delimitador de quadro for detectado em um intervalo de tempo, antes da leitura de RSSI, este intervalo de tempo não deverá ser usado para a atualização de PDF de RSSI. Se um começo de um delimitador de quadro for detectado em um intervalo de tempo, após a leitura de RSSI, este intervalo de tempo poderá ser usado para uma atualização de PDF de RSSI. A finalidade disto é evitar que um tráfego de Linknet interfira com a aquisição de PDF. A meta desta medição é pegar uma imagem de fontes de interferências externas nos canais usados pela rede. Cada um dos contadores de intervalo (bin) começa a partir do zero, quando o processo é inicializado e tem uma faixa máxima de 4096. Quando qualquer um destes contadores atinge o valor máximo RSSI_PDF_Max_Count (< 4095), a aquisição de PDF de RSSI para aquele canal é parada. Quando a aquisição de PDF de RSSI está completada para os três canais selecionados, a camada de MAC poderá reportar os resultados para a camada de LLC. A estrutura da saída é mostrada na presente Figura 34.
Se o nó perder sincronização, comutar para uma outra célula ou experimentar uma falta de potência (isto poderia ser feito na ativação), todas as mensagens armazenadas em buffer devem ser apagadas.
A camada de MAC usa vários tipos de mensagens para gerenciamento de suas numerosas tarefas. Nem toda mensagem contém o mesmo nível de informação. De modo a se poupar largura de banda de RF e para não enviar bytes inúteis, o cabeçalho de MAC será diferente para quase cada tipo de mensagem. Contudo, toda mensagem deve prover uma informação de sincronização para qualquer um que queira ouvi-la. Desta forma, nenhuma mensagem será inútil, mesmo se uma mensagem for ouvida por um ponto final que não seja o destino.
No nível de camada de MAC, o endereço de um ponto final é o número de série do medidor em si. Assim, um endereço é fixo e único, e é de 4 bytes de comprimento.
O quadro de mensagem no nível de MAC é comporto por:
• Um cabeçalho de MAC: ele representa todos os parâmetros necessários no nível de MAC. Nós podemos dividi-lo em subseções: uma parte comum para todos os tipos de mensagem e uma parte dinâmica.
• Um corpo de quadro, o qual é a unidade de dados de protocolo de LLC, denominado LPDU.
• Uma seção de seqüência de verificação de quadro, a qual é dos bytes necessários para a computação da detecção de erro no cabeçalho de MAC e no corpo de quadro.
A presente Figura 3 5 abaixo mostra todos os campos que podem estar presentes no nível de MAC. 0 campo e as estruturas de mensagem diferentes são descritas de outra forma aqui.
De acordo com o presente assunto, há uma parte do cabeçalho a qual é comum a todos os tipos de mensagens:
LV, Layer Version (versão de camada): indica a versão da camada de MAC.
FT, Frame Type (tipo de quadro) : estes bits indicam o tipo do quadro. Veja as seções relativas da presente Figura 36 para a informação relacionada ao tipo de quadro de MAC. Note que os tipos de mensagem são dispostos em ordem de prioridade.
SA, Sender Address (endereço de remetente): o endereço de remetente / fonte tem 4 bytes de comprimento.
O cabeçalho de MAC tem uma seção dinâmica, na qual os campos abaixo não aparecem em toda mensagem. Eles são descritos aqui de forma geral, com maiores detalhes declarados de outra forma aqui para cada tipo de mensagem. RS, Estado de Registro:
Indica se o ponto final está registrado para uma célula ou não. Esta informação é provida pela camada de NET.
O bit de RS do mestre de célula sempre é 1. RSD, Reservado:
Não usado no momento. Este campo deve ser regulado para 0.
CD, Grau de Conectividade:
Este campo indica o grau de conectividade do nó com seus pais. Dependendo do número de pais de SYNC potenciais que o nó tiver, o grau de conectividade assume um valor diferente.
O valor de CD do mestre de célula sempre é regulado para o valor máximo.
CSI, Indicador de tamanho de célula:
Indica quão cheia está a célula. LVL, Nível:
Este campo indica o nivel do remetente. Um transmissor de nível 0 sinaliza que o transmissor não está conectado à rede de malha. Um transmissor de nível 1 indica que o transmissor é um mestre de célula. Para o outro valor, se η for o número de saltos para atingir o mestre de célula, o nível será definido por LVL=n+l.
GPD, Atraso de propagação global:
Este campo indica o atraso de propagação global entre o remetente e o mestre de célula.
SACT, Temporizador de contagem regressiva de Aloha com intervalo: Este campo indica o tempo remanescente antes de o ponto final comutar para o próximo intervalo de tempo, quando o transmissor envia a mensagem. 0 SACT é expresso em MAC_SACT_Resolution ps.
TSN, Número de intervalo de tempo:
Este campo proporciona o número de intervalo de tempo no qual a mensagem é enviada. Combinado com o endereço de célula (CELL), qualquer ponto final pode deduzir o canal deste intervalo de tempo. CELL, Endereço de célula:
Este campo proporciona o endereço da célula com a qual o ponto final está sincronizado. Estes 2 bytes são usados para a computação da seqüência de salto de freqüência usada na célula. Em um sinal de orientação de descoberta, este campo é usado para a especificação da célula preferida em uma partida a quente. 0 endereço de camada de eletrodo é baseado no endereço C12.22 da placa de WAN de relê de célula.
FID, ID de quadro:
0 ID de quadro é incrementado e enviado em cada requisição de Sync e dados de monodifusão; ele é enviado no (N)ACK ou SYNC_(N)ACK para especificação do pacote a que ele está respondendo. OID, ID de falta:
O número de falta do ponto final que experimenta uma falta de potência. DA, Endereço de destino:
O endereço de destino é de 4 bytes de comprimento. HFN, Número de hiperquadro.
O número de hiperquadro pode ser usado de várias formas, dependendo do tipo de mensagem. RITP, ITP relativo:
O ITP relativo é propagado na rede através de um tipo dedicado de mensagem. Este é a estampa de tempo de ITP do começo do número de hiperquadro 0. RxC, Canal de recepção:
Este campo indica o número de canal no qual o EP ouvirá durante a janela de escuta da fase de descoberta. NDB, Número de sinais de orientação de descoberta remanescentes:
Ele proporciona o número de sinais de orientação de descoberta remanescentes a enviar antes do começo da janela de escuta.
O corpo de quadro está presente apenas em uma mensagem de dados, isto é, em mensagens a partir de camadas acima. Este campo não existe para as outras mensagens:
LPDU, unidade de dados de protocolo de LLC: este campo porta a mensagem para as camadas acima da camada de MAC.
O campo de seqüência de verificação de quadro (FCS) é usado para a detecção de erros em potencial no quadro:
CRC, código de redundância cíclica: estes 4 bytes são alocados para um valor CRC-32 para a verificação da integridade do cabeçalho de MAC e do corpo de quadro.
Os sinais de orientação são mensagens vazias sem um destino específico. Eles contêm apenas uma informação de sincronização; um ponto final envia sinais de orientação periodicamente quando ele não gera qualquer outro tráfego.
O comprimento de sinal de orientação no nível de MAC é de 19 bytes, conforme representado graficamente na Figura 37.
Uma requisição de SYNC é enviada por um ponto final que quer se tornar sincronizado com um outro. O campo de FID é um contador, incrementado em cada Requisição de SYNC ou Dado de Monodifusão enviado. O comprimento de requisição de SYNC no nível de MAC é de 2 4 bytes, conforme representado graficamente pela presente Figura 38.
Os tipos a seguir de mensagens são usados para reconhecimento ou não de mensagens de dados e requisições de SYNC. O campo de FID difere do FID da mensagem a qual é (não) reconhecida. O comprimento de (N)ACK ou SYNC NACK no nível de MAC é de 24 bytes, conforme representado graficamente pela presente Figura 39.
Uma mensagem de SYNC ACK é um reconhecimento de uma requisição de SYNC. O campo de FID se refere ao FID da mensagem de requisição de SYNC a qual é reconhecida. Ela difere de SYNC NACK porque o número de hiperquadro atual, HFN, e o ITP relativo deste hiperquadro também são transmitidos. O comprimento de SYNC ACK no nível de MAC é de 29 bytes, conforme representado graficamente pela Figura 40. Uma nota especial é que esta mensagem não se ajusta em um único subintervalo de tempo (para 1 byte).
Se um ponto final precisar atualizar a informação de sincronização de um de seus vizinhos ou apenas checar se ele ainda está presente, ele poderá enviar um sinal de orientação de requisição. O comprimento de sinal de orientação de requisição no nível de MAC é de 23 bytes, conforme representado graficamente pela Figura 41.
A mensagem de dados de monodifusão é uma mensagem de dados enviada apenas para um destino. Ela contém o corpo de quadro que a LPDU porta. O campo de FID é um contador, incrementado em cada requisição de dados de monodifusão ou SYNC enviada. O comprimento de quadro de MAC de monodifusão é de comprimento de LPDU + 24 bytes, conforme representado graficamente pela Figura 42.
A difusão é uma mensagem de dados não endereçada a qualquer um em particular, mas pretendida para qualquer ponto final recebendo-a. o comprimento de quadro de MAC de difusão é de comprimento de LPDU + 19 bytes, conforme representado graficamente pela Figura 43.
As mensagens de ITP são mensagens dedicadas, inicializadas pelo mestre de célula, para a propagação do RITP na célula inteira. Elas são consideradas como mensagens de dados de difusão sem um corpo de quadro. O campo de RITP é fixado pelo mestre de célula, quando ele inicializa a mensagem, como o campo de HFN, o qual é o número de hiperquadro da criação do RITP. Quando os EPs encaminham a mensagem de ITP, eles mantêm os mesmos campos de HFN e RITP que aqueles criados pelo mestre de célula. O comprimento de ITP no nível de MAC é de 24 bytes, conforme representado graficamente pela Figura 44.
O sinal de orientação de descoberta é uma mensagem curta enviada durante a fase de descoberta por EPs não sincronizados. O campo RxC indica o canal de escuta da fase de descoberta, NDB o número de sinais de orientação de descoberta remanescentes a enviar antes da janela de escuta, e CELL é regulado para o endereço de célula com que o nó deseja se sincronizar, em uma partida a quente (regulado para 0 em uma partida a frio). O comprimento de sinal de orientação de descoberta no nível de MAC é de 13 bytes, conforme representado graficamente pela Figura 45.
As mensagens de falta são as mensagens mais simples e mais curtas que podem ser enviadas. Quando um ponto final percebe que há uma falta de potência, ele usa seu último suspiro para enviar várias destas mensagens. O OID proporciona o número de falta. Em cada nova falta, o EP incrementa este número de falta, o qual rola em um 1 byte.
Para cada falta, três mensagens de falta são enviadas randomizadas em três intervalos de 5 segundos (o OID fica o mesmo para estes três pacotes). O comprimento de mensagem de falta no nivel de MAC é de 10 bytes, conforme representado graficamente pela Figura 46.
A presente Figura 47 representa esquematicamente os Serviços de Camada de MAC, os quais refletem uma funcionalidade vantajosamente provida pelo presente assunto de protocolo. Especificamente, com um objetivo de enviar uma mensagem para um destino, MAC_Request_Send_Mono_Data, há o uso de argumentos de entrada requisitados: LPDU, Endereço de destino. A operação pode ser descrita como a camada de LLC requisitando que a camada de MAC envie uma mensagem para um vizinho. A mensagem é enviada com regras de gerenciamento de tráfego padronizadas. Note que o vizinho não está necessariamente na tabela de vizinho.
Com um objetivo de enviar uma mensagem de difusão, MAC_Request_Send_Broadcast, há o uso de argumentos de entrada requisitados: LPDU. A operação pode ser descrita como a camada de LLC requisitando que a camada de MAC envie uma mensagem para todo mundo na vizinhança. A mensagem é enviada com as regras de gerenciamento de tráfego padronizadas.
Com o objetivo de enviar uma estampa de tempo de RITP, MAC_Request_Send_ITP, não há argumentos de entrada requisitados. A operação pode ser descrita como a camada de NET requisitando que a camada de MAC, por meio da LLC, envie uma mensagem de ITP para todo mundo na vizinhança. Esta requisição segue a mesma abordagem que uma MAC_Request_Send_Broadcast, exceto pelo fato de não haver uma LPDU a portar. Ao invés da LPDU, o MAC adiciona em seu cabeçalho o RITP e o HFN da criação deste RITP. A mensagem é enviada com as regras de gerenciamento de tráfego padronizadas.
Com um objetivo de medir o nível de interferência médio em um canal especificado e sua função de autocorrelação de tempo,
MAC Request_Environment_Analysis_Auto-Correlation, há um uso dos argumentos de entrada requisitados: Número de canal (Channel number), Número de amostras (Number of samples). A operação pode ser descrita como a camada de API requisitando, por meio das camadas de LLC e de NET, que a camada de MAC meça o RSSI em um canal especificado, um dado número de vezes. A camada de MAC então computará o valor médio deste RSSI, bem como sua função de autocorrelação. A taxa de aquisição de amostragem do RSSI é um parâmetro de MAC, MAC_RSSI_Sampling_Rate. Os valores dos atrasos para a computação da função de autocorrelação são dados por um outro parâmetro de MAC, MAC_RSSI_AF_Delays.
Com um objetivo de medir o nível de interferência médio de três canais especificados e sua função densidade de probabilidade, MAC_Request_Environment_Analysis_PDF, há o uso dos argumentos de entrada requisitados: Channel numbers (3), RSSI_PDF_Max_Count (valor máximo de contadores de intervalo (bin)). A operação pode ser descrita como a camada de API requisitando, por meio das camadas de LLC e NET, que a camada de MAC meça o RSSI em três canais especificados tomados da seqüência de salto. Para cada um destes canais, a camada de MAC computará a função densidade de probabilidade (PDF) de RSSI. O processo de aquisição pára quando um contador de intervalo (bin) atinge o valor máximo admitido para aquela requisição.
Com um objetivo de proporcionar à camada de MAC a informação quanto a se uma célula está autorizada ou não, MAC_Request_Cell_Authorization, há o uso dos argumentos de entrada requisitados: endereço de célula, status de célula. A operação pode ser descrita como a camada de NET proporcionando, por meio da camada de LLC, para a camada de MAC o status de uma célula. Este pode ser autorizado ou proibido.
Com um objetivo de proporcionar à camada de MAC a informação quanto a se a camada de NET está registrada, MAC_Request_Cell_Registration, há o uso dos argumentos de entrada requisitados: endereço de célula, status de registro. A operação pode ser descrita como a camada de NET informando, por meio da camada de LLC, o status de registro de NET na célula. Então, a camada de MAC pode regular o bit de RS (estado registrado) para 0 ou 1 em seu cabeçalho.
Com um objetivo de responder a uma MAC_Request_Send_Mono_Data, MAC_Confirmation_Send_Mono_Data, há o uso dos argumentos de saída requisitados: status da mensagem (ACK, NACK, Nenhum ACK). A operação pode ser descrita como se proporcionando à camada de LLC o status de uma Requisição de Enviar Dados de Mono. Cada confirmação é ligada ao número da requisição associada, para se evitar uma confusão. A confirmação pode ser um ACK ou um NACK, se essas mensagens tiverem sido recebidas, ou um status de Nenhum ACK, se o destino não tiver respondido no intervalo de tempo em que deveria.
Com um objetivo de responder a uma MAC_Request_Send_Broadcast e MAC_Request_Send_ITP, MAC_Confirmation_Send_Broadcast e
MAC_Confirmation_Send_ITP, há o uso dos argumentos de saída requisitados: Status. A operação pode ser descrita como se confirmando para a LLC quando a difusão ou o ITP foi enviado. Então, a LLC pode prosseguir para a repetição, se necessário.
Com um objetivo de responder a uma MAC_Request__Environment_Analysis_Auto-Corre Iat ion, MAC_Confirmation_Enviroximent_Analysis_Auto - Correlat ion, há o uso dos argumentos de saída requisitados: RSSI médio, valores de função de autocorrelação de RSSI. A operação pode ser descrita como a camada de MAC enviando para a camada acima o valor médio de RSSI e os valores da função de autocorrelação computados durante a análise ambiental requisitada. O número de valores para a função de autocorrelação é o número de atrasos em que esta função foi calculada. Estes atrasos são definidos pelo parâmetro de camada de MAC MAC_RSSI_AF_Delays.
Com um objetivo de responder a uma MAC_Request_Environment_Analysis_PDF, MAC_Confirmation_Environment_Analysis_PDF, há o uso dos argumentos de saída requisitados: valores de PDF de RSSI para os três canais requisitados (3 χ 24 valores). A operação pode ser descrita como a camada de MAC enviando para a camada acima os valores de PDF de RSSI (realmente, os valores dos contadores de intervalo (bin) para cada um dos três canais requisitados.
Com um objetivo de responder a uma
MAC_Request_Cell_Autorization,
MAC_Confirmation_Cell_Authorization, há o uso dos argumentos de saída requisitados: Status. A operação pode ser descrita como apenas se confirmando que a requisição foi levada em consideração.
Com um objetivo de responder a uma MAC_Request_Cell_Registration,
MAC Confirmation_Cell_Registration, há o uso dos argumentos de saída requisitados: Status. A operação pode ser descrita como apenas se confirmando que a requisição foi levada em consideração.
Com um objetivo de encaminhar uma mensagem de LPDU recebida para a camada de LLC, MAC_Indication_Received, há o uso dos argumentos de saída requisitados: LPDU, endereço de remetente. A operação pode ser descrita como se proporcionando à camada de LLC a LPDU que foi recebida com o endereço de remetente.
Com um objetivo de informar que uma mensagem de ITP de difusão foi recebida, MAC_Indication_ITP_Received, não há o uso de quaisquer argumentos de saída. A operação pode ser descrita como quando uma mensagem de ITP de difusão válida é recebida, a camada de MAC atualiza o campo de RITP e informa à camada de NET, por meio da camada de LLC, aquela chegada. O resultado desta indicação força a camada de NET a encaminhar seu ITP, caso ainda não o tenha feito.
Com um objetivo de atualizar o ITP da camada de API, MAC_Indication_ITP_Update, há o uso dos argumentos de saída requisitados: estampa de tempo de ITP absoluta. A operação pode ser descrita como o RITP podendo ser atualizado após a recepção de uma mensagem de difusão ou de um SYNC ACK. A camada de MAC então computa uma atualização do ITP absoluto e a envia para a camada de API. Assim que o ITP seja computado, ele deve ser proporcionado à camada de API muito rapidamente. Esta indicação tem prioridade em relação a todas as outras indicações.
Com um objetivo de indicar para a camada acima o estado de MAC, MAC_Indication_State, há o uso dos argumentos de saída requisitados: estado, endereço de célula. A operação pode ser descrita como a camada de MAC informando às camadas superiores após cada modificação de estado. A camada de MAC pode ser não sincronizada ou sincronizada com uma célula. No último caso, o endereço da célula é indicado.
Com um objetivo de indicar para a camada acima que a camada de MAC logo deixará a célula atual, MAC_Indication_Cell_Leaving_process, não há o uso de quaisquer argumentos de saída. A operação pode ser descrita como a camada de MAC informando às camadas superiores que ela descobriu uma nova célula e deixará logo aquela atual.
Com um objetivo de informar que uma notificação de falta de potência foi recebida,
MAC_Indication_Outage_Received, há o uso dos argumentos de saída requisitados: ID de falta, endereço de remetente, tempo de falta. A operação pode ser descrita como sendo indicado para a camada de Net, por meio da LLC, que um vizinho experimentou uma falta em um dado tempo. Ela força a camada de NET a encaminhar esta notificação para o mestre de célula.
A camada de MAC é organizada em três modos: o modo não sincronizado, o modo de sincronização e o modo sincronizado. Quando um medidor é comutado para ligado ou após um blecaute, a camada de MAC vai para o modo não sincronizado. A presente Figura 4 8 representa esses recursos e outros aspectos, incluindo uma exposição adicional referente ao assunto de diagrama de estado de MAC.
A camada de controle de enlace lógico é a segunda subcamada da camada de enlace de dados, seguindo-se à camada de Net. Sua meta é prover outras funcionalidades que podem operar independentemente acima daquelas da camada de MAC, mas ainda têm a meta de otimização do acesso ao meio.
Alguns serviços providos pela camada de MAC são inúteis sem a camada de LLC, ao invés disso eles sendo pretendidos para as camadas acima da camada de enlace de dados, tal como a camada de NET. Portanto, de modo a não romper a abordagem de camada, alguns serviços são meramente encaminhados a partir da MAC para a camada de NET, e vice- versa, passando através da camada de LLC como se ela fosse um tubo.
A listagem a seguir descreve os parâmetros ajustáveis (isto é, passíveis de tweak) da camada de LLC com seus valores padronizados preferidos associados sendo referenciados na presente Figura 49.
LLC_ Duplication_Table_Siζe
Descrição: 0 número de entradas de mensagens de LLC salvas na memória para se evitarem mensagens duplicadas, quando o mesmo pacote é recebido várias vezes.
LLC_Max_Message_Length
Descrição: O comprimento de mensagem máximo que a camada de LLC permite que a camada superior envie.
Comentário: isto inclui o serviço de fragmentação e, assim, é obtido indiretamente pela equação:
LLC_Max_Message JLength = LLC_Max_Packet_Length *
LLC_Max_Nb_of_Packets
LLC_Max_Nb_of_Packets
Descrição: O número máximo de pacotes em que a LLC pode fragmentar uma mensagem.
LLC _Max_Nb_of_Downlink_ Transmissions:
Descrição: O número máximo de vezes que um pacote de enlace descendente deve ser enviado, se nenhum reconhecimento for recebido. LLC__Max_Nb_ of_üplink_ Tran smissions:
Descrição: O número máximo de vezes que um pacote de enlace ascendente deve ser enviado, se nenhum reconhecimento for recebido.
LLC_Max_Packet _Length
Descrição: O comprimento de pacote de NETPDU máximo que a camada de LLC permite que a camada superior envie em um intervalo de tempo.
Comentário: LLC_Max_Packet_Length
MAC_Max_Packet_Length - LLC_Header_Length LLC_Message_Timeout
Descrição: Especifica um limite de tempo para a transmissão / recepção de uma mensagem fragmentada.
LLC Nb of Broacast Transmissions Descrição: O número de vezes que uma difusão é enviada
LLC_Tx_Retry_Exp_Offset
Descrição: Este parâmetro controla a inclinação inicial da lei de período de retorno após colisão exponencial para a repetição.
LLC_Tx_Retry_Exp_Range
Descrição: Isto é usado para a computação do número de repetição a partir do qual a lei de período de retorno após colisão exponencial binária é truncada.
LLC_Tx_Retry_Exp_Start
Descrição: O número de repetição a partir do qual a lei de período de retorno após colisão exponencial binária é aplicada para uma computação de janela de randomização de nova tentativa de transmissão. Comentário: Este valor deve ser menor do que o número máximo de transmissões para pacotes de enlace ascendente e de enlace descendente para que o período de retorno após colisão exponencial seja usado.
Comentário: Este valor deve ser menor do que (LLC_Max_Nb_of_Transmissions - LLC_Tx_Retry_Exp_Start) para que o truncamento ocorra.
Cada mensagem de monodifusão enviada pela camada de LLC deve ser reconhecida no nível de camada de MAC. Muito freqüentemente calhará de a camada de MAC reportar que ela não recebeu este reconhecimento. Isto pode ocorrer se o ponto final de destino falhar em receber a mensagem ou se o remetente falhar em receber o reconhecimento, devido a colisões, interferência ou desvanecimento. Em qualquer caso de falha, a camada de LLC enviará a mensagem de novo até ser reconhecida ou até o número máximo de tentativas ser atingido. Após LLC_Max_Nb_of_Downlink_Transm.issions ou LLC_M ax_Nb_of _Uplink_Transmissionstransmissões mal sucedidas, a camada de LLC reporta um status de falha de No-ACK para a camada de NET.
Para dados de difusão ou ITP, a LLC automaticamente repetirá a mensagem até o algoritmo de período de retorno após colisão, uma vez que a camada de MAC tenha notificado que o envio anterior se foi e isto até o número especificado de tentativas,
Number_of_Broacast_Transmissions , seratingido. Quando a camada de LLC recebe a partir da camada de NET uma requisição para enviar um pacote, ou quando ela reprograma uma transmissão não reconhecida, ela introduzirá um atraso randômico antes de realmente enviar a requisição para a camada de MAC. A finalidade deste atraso é evitar inundar a interface de ar com um grande número de pacotes, quando as condições de transmissão forem difíceis. A camada de MAC computará o comprimento de uma janela de randomização, Tx_Wait, e enviará a requisição real para a camada de MAC, após um atraso randômico, com uma distribuição de probabilidade uniforme entre O e Tx_Wait. O valor de Tx_Wait é computado como uma função do número de repetição. Tx_Wait é computado de acordo com uma lei de período de retorno após colisão exponencial binária truncada, conforme dado pela equação a seguir:
<formula>formula see original document page 272</formula> Aqui, R é o número de repetição: ele varia de zero à primeira tentativa de transmissão até algum valor máximo dado por (LLC_Max_Nb_of_Transmisions - 1). A aplicação desta lei de período de retorno após colisão exponencial é atrasada e truncada, conforme pode ser visto a partir da equação acima. Isto também é ilustrado pela presente Figura 50, a qual representa graficamente o período de retorno após colisão exponencial binário truncado atrasado para novas tentativas de transmissão, se os pacotes não forem reconhecidos. O raciocínio por trás disto é simples e pode ser explicado da forma a seguir. No período de "sem tempo de espera", o transmissor está tentando canais diferentes para se evitar uma interferência ou condições de propagação difíceis. No "período de retorno após colisão exponencial binário", o transmissor está progressivamente aumentando σ tempo de espera para permitir que a rede se recupere de condições não usualmente difíceis (quaisquer que elas sejam). O "período de retorno após colisão exponencial truncado" é necessário para se evitar a introdução de tempos de espera longos de forma não realista no sistema.
O começo e o fim da lei de período de retorno após colisão exponencial binário são dados por dois parâmetros de camada de LLC:
<formula>formula see original document page 273</formula>
Um parâmetro adicional introduz um desvio na aplicação da lei exponencial e proporciona uma forma de controle da informação inicial:
<formula>formula see original document page 273</formula>
O exemplo a seguir ilustra o algoritmo de janela de randomização de retransmissão para Rstart = 5, Rrange = 5, Roffset = 2, LLC_Max_Nb_of_Transmissions =15, e TS_Length = 1. A primeira coluna (R = 0) corresponde à tentativa de transmissão inicial.
<table>table see original document page 274</column></row><table>
Se um pacote for reconhecido negativamente (NACK), a fase "sem tempo de espera" da estratégia de retransmissão deve ser desviada, porque, neste caso, nós sabemos que o que aconteceu não é devido a um problema de propagação ou interferência (veja o apêndice). Por razões similares, no caso especial de transmissão de difusão, o período de retorno após colisão exponencial não atrasado deve ser usado. As difusões geram uma rajada de tráfego e colisões internas entre nós da rede têm probabilidade de ocorrerem e desaceleram a difusão. 0 uso imediato de um período de retorno após colisão exponencial pode mitigar este problema. Veja também a presente Figura 51, a qual representa graficamente um período de retorno após colisão exponencial binário truncado para novas tentativas de transmissão, se os pacotes forem reconhecidos negativamente. Nestes casos, a lei de repetição é dada por:
<table>table see original document page 274</column></row><table>
Se este pacote não for reconhecido e reconhecido mais tarde negativamente em uma tentativa de transmissão subseqüente, a lei de nova tentativa para pacotes reconhecidos negativamente deve ser aplicada. Da mesma forma, se um pacote foi reconhecido negativamente e uma nova tentativa mais tarde não for reconhecida, a lei de nova tentativa para pacotes reconhecidos negativamente deverá ser mantida.
A camada de LLC oferece um serviço não de duplicação. Devido ao fato de os meios de RF gerarem um grande número de colisões, a camada de LLC pode enviar uma mensagem mais de uma vez, e também receber o mesmo pacote várias vezes. Para se evitar encaminhar a mensagem recebida para a camada de NET várias vezes, cada pacote transmitido tem um número de LLC, LLC FID. Veja a presente Figura 52 para um exemplo de urna Tabela de Duplicação de LLC. Devido a este número, a camada de LLC sabe se o pacote já foi recebido. Caso isso aconteça, o pacote é descartado.
Em cada nova recepção, o número de mensagem, o número de pacote e o endereço de remetente são salvos em um FIFO, o qual contém as propriedades das LLC_Duplication_Table_Size últimas mensagens. Então, a entrada mais antiga é substituída pela nova, caso já não esteja presente na tabela. Se uma mensagem duplicada for recebida, a entrada existente associada na tabela precisará ser removida e reescrita como uma nova entrada. Isto assegurará que esta entrada permaneça mais tempo na tabela.
Deve ser notado que na recepção de uma mensagem, a detecção de pacotes duplicados deve ser feita antes da operação de reconstituição de uma mensagem fragmentada.
Se o nó perder a sincronização, comutar para uma outra célula ou experimentar uma falta de potência (isto poderia ser feito na ativação) , a tabela de duplicação será limpa.
Um outro serviço oferecido pela camada de LLC é a fragmentação de mensagens. A camada de LLC oferece a camada superior para enviar mensagens de extensão de até LLC_Max_Message_Length bytes, um tamanho que pode ser mais longo do que aquele oferecido pela material de construção, o qual é limitado pelo comprimento de intervalo de tempo. LLC_Max_Message_Length é limitado pelo tamanho físico da memória de dispositivo que roda o protocolo e pelo fato de a camada de LLC não puder lidar com mais de 15 pacotes.
Se a camada de NET pedir para enviar uma mensagem maior do que a camada de MAC pode enviar, a camada de LLC dividirá a mensagem em vários pacotes mais curtos. 0 número de pacote e o número de pacotes são mencionados no cabeçalho de LLC para se permitir a reconstituição da mensagem inteira na recepção.
Cada pacote corresponde a uma requisição individual enviada para a camada de MAC. A camada de MAC treta estes pacotes como mensagens completas regulares.
A camada de LLC computa o número requerido de pacotes, dependendo do comprimento de mensagem e do tamanho máximo com que a camada de MAC pode lidar.
A partir de uma perspectiva de lado de transmissor, a camada de LLC divide a mensagem em pacotes. Uma requisição de MAC é associada a cada pacote. Quando o primeiro pacote é enviado, um contador de expiração do comprimento de LLC_Message_Timeout é começado. Cada pacote pode ser enviado várias vezes, com a mesma limitação de repetição que para um pacote padrão, até o pacote ser reconhecido pela camada de MAC. Quando todos os pacotes tiverem sido reconhecidos, a camada de LLC confirma para a camada de NET que a mensagem foi enviada com sucesso. Se um pacote não tiver sido enviado corretamente ou se o contador atingir LLC_Message_Timeout, a camada de LLC informará a camada de NET que a transmissão falhou.
Da perspectiva do lado de receptor, a camada de LLC de receptor quando recebe o primeiro pacote de uma mensagem fragmentada, começa o mesmo contador de comprimento de LLC_Message_Timeout que aquele do lado de transmissor. Quando todos os pacotes tiverem sido recebidos, a camada de LLC gera de novo a mensagem inteira e a dá para a camada de Net. Se o contador atingir o valor LLC_Message_Timeout e pelo menos um pacote ainda estiver faltando, todos os outros pacotes serão apagados.
O valor de LLC_Message_Timeout deve ser longo o bastante para deixar a camada de MAC enviar corretamente todos os pacotes. O valor pode depender do número de pacote a enviar.
O presente assunto de protocolo oferece um tipo de serviço de difusão, ou, mais especificamente, uma de multidifusão. A função é que a mesma mensagem possa ser enviada para todos os pontos finais de uma célula. Isto é uma difusão verdadeira, a qual não é reconhecida, mas simplesmente transmitindo Number_of_Broacast_Transmissions vezes por cada ponto final. Pretende-se que qualquer ponto final a ouça (exceto o mestre de célula, onde as difusões se originam).
O cabeçalho de LLC é de 3 bytes de comprimento, conforme representado pela presente Figura 53, a qual de outra forma representa o quadro de LLC pleno. Nessa representação, a informação de quadro adicional a seguir é aplicável, conforme será entendido por alguém de conhecimento comum na técnica, sem uma explicação detalhada adicional.
LV, Versão de Camada:
0 número de versão de camada. RSD, Reservado:
Não usado inicialmente. Regulado para 0. FID, ID de Quadro:
Este byte indica o número de mensagem para se evitar uma duplicação de um pacote. NOP, Número de Pacotes:
Estes 4 bits proporcionam o número de pacotes que têm que ser transmitidos para a reconstrução dos dados. Isto implica que o protocolo pode dividir mensagens em um máximo de 15 pacotes. PN, Número de Pacote:
Estes 4 bits proporcionam o número de pacote dos dados fragmentados. Zero corresponde ao primeiro pacote. Adicionalmente, a unidade de dados de protocolo de NET (NETPDU) contém uma informação relativa à camada de rede.
A camada de LLC tem uma variedade de interfaces e serviços associados (funcionalidade) , conforme representado em detalhes pela presente Figura 54 . A camada de LLC assegura uma funcionalidade confiável, não apenas de si mesma, mas nos serviços que provê para aqueles em relação com ela, tal como resultando em a camada de LLC gerenciar a repetição e a fragmentação de mensagens. Por exemplo, dependendo de (não) reconhecimentos, a camada de LLC escolhe se o pacote tem que ser retransmitido ou não.
Com um objetivo de enviar uma mensagem para um destino, LLC_Request_Send_Mono_Data, há o uso de argumentos de entrada requisitados: NETPDU, e Endereço de destino. A operação pode ser descrita como a camada de NET requisitando que a camada de LLC envie uma mensagem para um de seus vizinhos. A camada de LLC fragmenta a mensagem em vários pacotes, se necessário, para se proporcioná-la para a camada de MAC. A camada de LLC também tenta enviar a mensagem várias vezes, antes de reportar um sucesso ou um erro para a camada de NET.
Com um objetivo de enviar uma mensagem para a vizinhança, LLC_Request_Send_Broadcast, há o uso de argumentos de entrada requisitados NETPDU. A operação pode ser descrita como a camada de NET requisitando que a camada de LLC envie uma mensagem para todos os vizinhos de ponto finai. A camada de LLC fragmenta a mensagem em vários pacotes, se necessário, para se proporcioná-la para a camada de MAC. A difusão é repetida Number_of_Broacast_Transmissions vezes.
Com um objetivo de enviar uma estampa de tempo de RITP para a vizinhança, LLC_Request_Send_ITP, não há o uso de argumentos. A operação pode ser descrita como a camada de NET requisitando que a camada de LLC envie uma mensagem de ITP para todos os vizinhos de ponto final. Esta requisição segue a mesma abordagem que uma LLC_Request_Send_Broadcast, exceto pelo fato de não haver nem NETPDU, nem LPDU. A LLC encaminha a requisição para a camada de MAC, a qual está encarregada da estampa de tempo da mensagem. A camada de LLC gerencia a repetição desta mensagem como uma difusão regular.
Com um objetivo de medir o nivel de interferência médio em um canal especificado e sua função de autocorrelação, LLC_Request_Environment_Analysis_Auto- Correlation, há o uso de argumentos de entrada requisitados: Número de canal, Número de amostras. A operação pode ser descrita como uma requisição sendo encaminhada para a camada de MAC.
Com um objetivo de medir o nível de interferência médio em três canais especificados e sua função densidade de probabilidade, LLC_Request_Environment_Analysis_PDF, há o uso de argumentos de entrada requisitados: Números de canal (3) , valor máximo de contador. A operação pode ser descrita como sendo uma requisição encaminhada diretamente para a camada de MAC.
Com um objetivo de proporcionar para a camada de MAC a informação quanto a se uma célula está autorizada ou não, LLC_Request_Cell_Authoriζation, há o uso de argumentos de entrada requisitados: Endereço de célula, Status de célula. A operação pode ser descrita como uma requisição sendo encaminhada diretamente para a camada de MAC.
Com um objetivo de proporcionar para a camada de MAC a informação quanto a se a camada de NET está registrada, LLC_Request_Cell_Registration, há o uso de argumentos de entrada requisitados: Endereço de célula, Status de registro. A operação pode ser descrita como uma requisição sendo encaminhada diretamente para a camada de MAC.
Com um objetivo de responder a um LLC_Request_Send_Mono_Data,
LLC_Confirmation_Send_Mono_Data, há o uso de argumentos de saída requisitados: ACK, NACK, Nenhum ACK, Endereço de destino do pacote enviado. A operação pode ser descrita como se confirmando para a camada de NET se a mensagem foi enviada com sucesso para o destino ou não. Caso não e se pelo menos um NACK tiver sido recebido, deve ser notificado para a camada de NET. A camada de NET então é capaz de escolher se ela tem que transmitir o pacote para um outro destino. Mediante o recebimento de uma confirmação de falha para uma mensagem de enlace ascendente, a camada de NET atualizará suas probabilidades de roteamento e enviará uma nova requisição para o LLC.
Com um objetivo de responder a um LLC_Request_Send_Broadcast e LLC_Request_Send_ITP, LLC_Confirmation_Send_Broadcast e
LLC_Confirmation_Send_ITP, há o uso de argumentos de saída requisitados: OK. A operação pode ser descrita como se confirmando para a camada de NET que a difusão foi enviada.
Com um objetivo de responder a um LLC_Reques t_Environment_Analysis__Auto-Correlation, LLC_ Conf irmation_Environinent_Analysis_Auto-Correlation, há o uso de argumentos de saída requisitados: RSSI médio, valores de função de autocorrelação de RSSI. A operação pode ser descrita como um encaminhamento de MAC_Confirmation_Environment_Analysis_Auto-Correlation a partir da camada de MAC para a camada de NET.
Com um objetivo de responder a um LLC_Request_Environment_Analysis_PDF,
LLC_Confirmation_Environment_Analysis_PDF, há o uso de argumentos de saída requisitados de valores de PDF de RSSI para os três canais requisitados (3 χ 24 valores). A operação pode ser descrita como um encaminhamento de um MAC_Confirmation_Environment_Analysis_PDF a partir da camada de MAC para a camada de NET. Com um objetivo de responder a um LLC_Request_Cell_Autorization,
LLC_Confirmation_Cell_Authorization, há o uso de argumentos de saída requisitados: Status. A operação pode ser descrita como um encaminhamento de
MAC_Conf i rmat ion_Ce1l_Authori zat ion a partir da camada de MAC para a camada de NET.
Com um objetivo de responder a um LLC_Request_Cell_Registration,
LLC_Confirmation_Cell Registration, há o uso de argumentos de saída requisitados: Status. A operação pode ser descrita como um encaminhamento de
MAC_Confirmation_Cell_Registration a partir da camada de MAC para a camada de NET.
Com um objetivo de encaminhar uma mensagem de NETPDU recebida para a camada de NET, LLC_Indication_Received, há o uso de argumentos de saída requisitados: NETPDU, Endereço de remetente. A operação pode ser descrita como após a montagem de todos os pacotes, se a mensagem tiver sido fragmentada, a camada de LLC proporcionar a mensagem de NETPDU para a camada de NET.
Com um objetivo de informar que uma material de edificação de ITP foi recebida, LLC_Indication_ITP_Received, não há o uso de quaisquer argumentos de saída. A operação pode ser descrita como um encaminhamento direto da MAC_Indication_ITP_Received a partir da camada de MAC para a camada de NET.
Com um objetivo de atualizar o ITP da camada de API, LLC_Indication_ITP_Update, há o uso dos argumentos de saída requisitados: Estampa de tempo de ITP absoluta. A operação pode ser descrita como um encaminhamento direto de MAC_Indication_ITP_Update a partir da camada de MAC para a camada de NET. Esta indicação tem prioridade em relação a todas as outras indicações.
Com um objetivo de indicar para a camada acima o estado de MAC, LLC_Indication_State, há o uso de argumentos de saida requisitados: Estado, Endereço de célula. A operação pode ser descrita como a camada de LLC obter esta indicação diretamente do MAC_Indication_State.
Com um objetivo de indicar para a camada acima que a camada de MAC logo deixará a célula atual, LLC_Indication_Cell_Leaving_process, não há o uso de quaisquer argumentos de saída. A operação pode ser descrita como um encaminhamento direto de MAC_Indication_Cell_Leaving_process a partir da camada de MAC para a camada de NET. Antes de encaminhar, a camada de LLC libera seus buffers e suas ações pendentes
Com um objetivo de informar que uma notificação de falta de potência foi recebida, LLC_Indication_Outage_Received, há o uso de argumentos de saída requisitados: ID de Falta, Endereço de remetente, Tempo de falta. A operação pode ser descrita como um encaminhamento direto de MAC_Indication_Outage_Received a partir da camada de MAC para a camada de NET.
O que vem a seguir se refere, mais particularmente, à camada de rede (NET). A camada de rede é a terceira camada do modelo de OSI e a camada mais alta do protocolo Linknet. É o coração do mecanismo de roteamento. Todos os pontos finais têm a mesma camada de rede, exceto pelo mestre de célula, o qual estendeu as funções de roteamento. A principal tarefa da camada de NET é decidir qual é o destino das mensagens, mas também está encarregada do processo de registro de célula, o qual é interno à RF LAN.
Pelo recurso de camada de NET de EP (ponto final) , a camada de NET encaminha qualquer mensagem para o próximo salto. Ela também provê dados sobre sua vizinhança para o relê de célula. Pela camada de NET de CR (relê de célula ou mestre de célula), a camada de NET se oferece para enviar para um EP (mensagem de enlace descendente) em particular na célula ou para a célula inteira (mensagem de difusão). A camada de NET de CR não se oferece para enviar uma mensagem para um conjunto especifico de EPs na célula. Também, a camada de rede está ativa apenas enquanto o ponto final estiver sincronizado, e deixará a camada de aplicativo usar a rede apenas se estiver registrada no nível de NET.
Os parâmetros de NET podem ser listados conforme se segue, incluindo suas respectivas identificações, descrições e valores padronizados: NET_Broadcast_Life_Expectancy:
Descrição: o tempo de vida máximo de uma difusão em uma célula, em número de hiperquadros. NET_CR_Downl inkJDupl icati onJTabl e_Si ze :
Descrição: 0 número de entradas de mensagem de enlace descendente de NET salvo na memória de mestre de célula para se evitarem mensagens em duplicata de enlace descendente, quando recebidas várias mensagens de enlace rompido a partir do mesmo enlace descendente.
NET_CR_DuplicationJTable_Size:
Descrição: 0 número de entradas de mensagem de NET salvas na memória de mestre de célula para se evitarem mensagens em duplicata, quando o mesmo pacote for recebido várias vezes.
NET_Down1ink_Life_Expectancy:
Descrição: O tempo de vida máximo de um enlace descendente em uma célula, em número de hiperquadros.
NET_Endpoint_TimeOut:
Descrição: O tempo após o qual um ponto final deve ser removido da tabela de roteamento de mestre de célula, se nenhuma mensagem tiver sido removida dali.
NET_EP_Duplication_Table_Size:
Descrição: O número de entradas de mensagem de NET salvas na memória de ponto final para se evitarem mensagens em duplicata, quando o mesmo pacote for recebido várias vezes.
NET_Max_Regi strati on__Attempts :
Descrição: O número máximo de tentativas de requisição de registro de célula que um ponto final pode enviar para uma dada célula, antes de declarar esta célula como proibida.
NET_Max_Nb_of_EPs:
Descrição: O número máximo de pontos finais por célula. Isto é útil para a camada de NET de mestre de célula, a qual pode decidir autorizar ou não um novo ponto final em sua célula. Também é o tamanho da tabela de roteamento de mestre de célula.
NET_Nb_of_Fathers_Routing:
Descrição: Quando do roteamento de uma mensagem para o mestre de célula, a camada de NET escolherá um pai dentre um subconjunto constituído pelos melhores pais para um roteamento. 0 tamanho deste subconjunto é NET_Nb_of_Fathers_Routing. NET_Nb_of_Endpoints_Neíghbor_List:
Descrição: Corresponde ao número máximo de pontos finais presentes em uma lista de vizinho. NET_Neighbor_List_First_Time:
Descrição: O tempo após o qual um ponto final deve enviar sua primeira lista de vizinho para o mestre de célula, quando se tornar sincronizado com uma célula, em um caso de partida a quente. NET_Neighbor_List_Max_Period:
Descrição: O período máximo entre duas transmissões da lista de vizinho para o mestre de célula, se esta lista não tiver mudado. NET_Nei ghbor__Li s t_Min_Peri od:
Descrição: o período mínimo entre duas transmissões da lista de vizinho para o mestre de célula, se esta lista tiver mudado. NET_Reg_Send_Config_Period.
Descrição: A taxa na qual o mestre de célula deve tentar enviar as confirmações de registro que estiverem pendentes. Ela pode ser mais lenta, se o buffer de enlace descendente estiver cheio, mas não deve ser mais rápida. NET_Registratíon_Retry:
Descrição: O período durante o qual um ponto final está esperando pela confirmação de registro para sua primeira requisição. Após a primeira requisição, este tempo é multiplicado pelo número de tentativas de requisição para se obter o período de espera. NET__Registration_Send_Max:
Descrição: Este parâmetro define o limite máximo da janela de randomização de NET na qual a requisição de registro deve ser enviada. NET_Registration_Send_Min:
Descrição: Este parâmetro define o limite inferior da janela de randomização de NET na qual a requisição de registro deve ser enviada. NET_ Uplink_Life_Expectancy:
Descrição: o tempo de vida máximo de um enlace descendente em uma célula, em número de hiperquadros. Com respeito à assim denominada tabela de vizinho, a camada de rede usa a tabela de vizinho da camada de MAC com direitos de leitura. Isto significa que a camada de rede não pode modificar os valores nessa tabela. A presente Figura 55 descreve o assunto de VALORES PADRÕES DE PARÂMETRO DE CAMADA DE REDE.
Antes da autorização de camadas superiores para se usar a rede, um ponto final deve ser registrado em um nível de camada de NET. O processo de registro de NET começa assim que o ponto final começa sua sincronização a partir da camada de MAC. Há duas formas de se proceder quanto a se o ponto final foi previamente registrado junto à célula, o que leva a um processo de partida a quente, ou se está se unindo a uma nova célula, o que leva a um processo de partida a frio.
O comportamento durante este processo de registro de célula também pode ser visto a partir de dois lados, o ponto final ou o mestre de célula.
No cenário de partida a frio, os eventos a seguir devem acontecer, antes de a camada de API poder acessar a rede:
A camada de MAC obtém uma sincronização com um de seus pais de SYNC potenciais e entra em uma nova célula.
A camada de NET é informada do status de sincronização e envia, randomicamente entre NET_Registration_Send_Min e
NET_Registration_Send_Max, uma requisição de registro de célula para o mestre de célula.
Então, o ponto final está esperando pela resposta:
1. Se não houver nenhuma resposta. Há um mecanismo de nova tentativa a cada (número de novas tentativas * NET_Registration_Retry) . Há um máximo de NET_Max_Registration_Attempts tentativas de registro com esta célula, antes de desistir; após isso, a célula é declarada como proibida e a camada de MAC deve procurar por uma outra célula(é lembrado que após
MAC_Unsynchronized_Timeout dias no modo de descoberta, a camada de MAC reautorizará todas as células).
Assim, com NET_Registration_Send_Min = 5 min, NET__Registration_Send_Max = 10 min, NET_Registration_Retry=1 hora,e NET_Max_Registration_Attempts =5, as requisições serão feitas nas janelas a seguir:
la tentativa: 5-10 min, 2a: 65-70 min, 3a: 185-190 min, 4a: 365-370 min, 5a: 605-610 min. A expiração corresponde ao começo de janela da próxima tentativa (ou a
NET_Max_Registration_Attempts *
NET_Registration_Retry para a última tentativa; horas)
2. Se uma notificação de célula fora de NET for recebida, a célula será imediatamente marcada como proibida e a camada de MAC procurará por uma outra célula.
3. Se uma confirmação de registro de célula de NET for recebida, o ponto final comutará para o estado registrado de NET.
Uma vez que o ponto final seja registrado na NET:
1. A NET informa à camada de MAC que agora regulará seu bit de RS para 1 em seu cabeçalho, o que significa que este ponto final agora pode ser usado como um pai de SYNC para seus vizinhos.
2. A NET informa à camada de API que ela agora está autorizada a enviar mensagens através da rede.
3 . A camada de NET começa a enviar periodicamente listas de vizinho (a requisição de registro de célula é considerada como uma, de modo que a primeira lista de vizinho real seja enviada após um período definido; isto é, NET_Neighbor_List__Min_Period hora, se nenhuma mudança tiver ocorrido).
Vários itens em particular são de nota:
Em qualquer momento, se um ponto final receber uma notificação de saída de célula de NET, ele deverá deixar a célula.
• Embora o ponto final não seja registrado, ele não pode ser usado como um pai de SYNC, já que não se adéqua à condição de pai de SYNC (RS = 0) .
• Durante o tempo de espera de confirmação de registro, nenhuma lista de vizinho é enviada.
• Como a camada de API não está autorizada a falar enquanto o ponto final ainda não tiver se registrado, o enlace ascendente com o tipo de pacote de lista de vizinho nunca é usado. Contudo, esta definição de pacote ainda é definida na especificação, já que pode ser usada um dia.
Nas circunstâncias de condição de partida a quente, é muito mais simples e mais rápido:
• A camada de MAC pega uma sincronização com um de seus pais de SYNC potenciais e recupera a célula na qual ela foi apropriadamente registrada.
• A camada de NET vai diretamente para o estado registrado e informa às camadas de MAC e de API.
• A camada de NET começa enviando periodicamente listas de vizinho. Uma vez que nenhuma requisição de registro de célula, a qual contém uma informação de lista de vizinho foi enviada, a primeira lista de vizinho é enviada após Neighbor__List_First_Tiiue minutos. Quando um mestre de célula recebe uma requisição de
registro de célula, ele deve enviar uma confirmação de registro de célula e atualizar sua tabela de roteamento com a nova informação (adicionar o ponto final se ele ainda não estiver ali) , a menos que a tabela de roteamento esteja cheia, em cujo caso ele deve enviar uma notificação de saída de célula. Para maiores detalhes sobre as ações de um mestre de célula quando recebendo um pacote, veja a exposição remanescente aqui.
Durante uma partida a frio, o mestre de célula está recebendo uma grande quantidade de requisições de registro de célula em uma janela de tempo estreita. Portanto, ele não tem tempo suficiente para enviar toda a confirmação de registro na mesma taxa em que recebe requisições. Como uma conseqüência, o mestre de célula deve manter um acompanhamento das requisições que ele recebe e, então, envia a confirmação de quando ele tem tempo de fazê-lo. Durante uma partida a frio de célula, o número de "registros pendentes" pode ser muito alto (em torno de metade do tamanho de célula).
A lista de registro pendente pode ser manipulada pela regulagem de um indicador tipo de flag na tabela de roteamento dos pontos finais correspondentes (1 bit * tamanho máximo de célula = 1 kb = 12 5 B) e periodicamente varre a tabela para saber quais pontos finais precisam de uma confirmação de registro.
O registro pendente também deve ser feito como uma lista de endereços a enviar uma confirmação; isto é uma transigência entre espaço de memória e tempo de execução de código e a escolha é deixada para a implementação.
Em ambos os casos, quando há muitas confirmações empilhadas, elas devem ser enviadas a uma taxa máxima de NET Reg_Config_Send_Period. É para assegurar não somos nós inundando a rede com mensagens de enlace descendente.
Quando um ponto final comutar de célula, ele se registrará na nova célula. A questão é que ele ainda está registrado na célula antiga; isto não é uma questão para roteamento, uma vez que o nível de API perceberá que o ponto final se moveu de célula, mas isto pode ser uma questão para gerenciamento de tamanho de célula. Efetivamente, o indicador de tamanho de célula (CSI) usado no processo de comutação de célula é com base no número de ponto final na tabela de roteamento de NET do mestre de célula e, se este número não refletir a realidade, então, o processo de comutação não funcionará mais apropriadamente.
É por isto que é importante que o mestre de célula antigo seja informado da partida de pontos finais de sua célula. Este é o papel da mensagem de notificação de saída de célula.
Assim que a camada de MAC notifica que um vizinho de uma célula melhor é alcançável, ela planeja uma requisição de SYNC e espera pelo SYNC ACK. 0 SYNC ACK recebido, a camada de MAC dispara algumas ações em cada camada:
• MAC:
Salvar uma informação de sincronismo relativa à nova célula e ao vizinho.
Começar um temporizador de comutação de célula de MAC_CELL_Leaving_Process_Duration segundos.
• LLC:
Liberar buffers e ações pendentes.
• NET:
Liberar buffers e ações pendentes.
Enviar uma notificação de saída de célula para o mestre de célula atual. Esta mensagem permitirá que o mestre de célula remova o ponto final de sua tabela de roteamento e atualize o tamanho de célula.
Durante MAC_CELL_Leaving_Process_Duration segundos, o ponto final atua como usual, exceto pelo fato de não poder decidir começar o mesmo processo com uma terceira célula. É implicado que durante este período o ponto final não terá tempo suficiente de enviar a mensagem de Net e também encaminhar o mesmo tipo de informação de filhos os quais decidem por eles mesmos mudarem de célula (eles provavelmente vêem a mesma nova célula ao mesmo tempo).
Quando o temporizador expira, qualquer que seja o status de mensagens remanescentes a enviar, a camada de MAC ressincroniza seu relógio e comuta para a nova célula. A camada de LLC e a de NET são notificadas por esta comutação. Portanto, elas liberam de novo seus buffers, ações pendentes... A camada de NET (e a de API) então é capaz de se registrar junto ao novo mestre de célula.
O algoritmo inteiro é com base no fato que todo ponto final na célula conhece sua vizinhança a 1 salto e não sabe nada além do alcance de 1 salto. A situação é ligeiramente diferente para o mestre de célula e será explicada em uma seção dedicada.
O protocolo caracteriza duas direções de roteamento diferentes, enlace ascendente e enlace descendente. O enlace ascendente é usado para um medidor enviar uma mensagem para o mestre de célula, e o enlace descendente é usado para o transporte de uma mensagem do mestre de célula para um medidor. Estas duas direções de roteamento usam mecanismos diferentes, conforme explicado abaixo.
Um outro mecanismo de roteamento é a difusão, usada para o transporte de uma mensagem para todo ponto final da célula.
Cada pacote que está indo através da camada de NET contém uma estampa de tempo de quando ele foi gerado. A cada vez em que um pacote é roteado no nível de camada de NET, o tempo de vida do pacote é checado em relação a sua expectativa de vida e é atrasado se for antigo demais.
Mais particularmente, para a realização de uma comunicação de enlace ascendente, o ponto final tem que enviar sua mensagem para o mestre de célula. O ponto final não sabe onde seu mestre de célula está, mas sabe que seus pais podem alcançá-lo. Portanto, ele tem que enviar a mensagem de enlace ascendente para um de seus pais. O protocolo deve limitar sua escolha para os NET_Nb_of_Fathers_Routing melhores pais, com base em SYNC Merit. Ele deve selecionar randomicamente um destes pais com uma probabilidade para cada pai inversamente proporcional a seu SYNCJVIerit e, então, enviar a mensagem de enlace ascendente para aquele pai. Todo pai sincronizado e registrado da célula é adequado para um roteamento de enlace ascendente.
Se a LLC reportar uma transmissão com falha (após todas as novas tentativas), a camada de NET olhará de novo na tabela de vizinho (a qual agora está atualizada de acordo com os resultados das tentativas prévias de transmissão), e selecionará de novo um pai randômico dentre os NET_Nb_of_Fathers_Routing melhores, usando o mesmo algoritmo de seleção probabilístico como na primeira instância. A mensagem de enlace ascendente então é encaminhada para a camada de LLC para transmissão para o pai recém selecionado. Este processo continua até a LLC reportar uma transmissão bem sucedida ou até o ponto final entrar em uma falha de potência, tornar-se dessincronizado ou comutar para uma nova célula.
Quando o pai selecionado receber esta mensagem de enlace ascendente, ele prosseguirá de uma forma similar. Este processo é repetido até o melhor pai ser o mestre de célula.
Antes de um pacote de enlace ascendente ser roteado para um dos pais de ponto final, a camada de NET checa se ele não é mais antigo do que NET_Uplink_Life_Expectancy. Se ele for mais antigo, então, será apagado.
Em contraste, para um percurso de enlace descendente, isto é, um envio de uma mensagem a partir do mestre de célula para um ponto final específico, é uma coisa muito fácil, ã medida que os pontos finais são concernidos. De fato, o percurso inteiro é indicado no cabeçalho de rede. Este percurso é especificado pelo mestre de célula, o qual tem um conhecimento completo de todos os pontos finais na célula.
Quando um ponto final recebe uma mensagem de enlace descendente, ele lê seu cabeçalho de rede e automaticamente encontra o próximo destino a contatar. Isto é repetido até o destino final ser atingido. Antes do encaminhamento da mensagem para o próximo nó, o ponto final remove seu próprio endereço do percurso de roteamento do cabeçalho de Net. 0 ponto final deve encaminhar a mensagem para o próximo endereço no cabeçalho, mesmo se este endereço não combinar com qualquer nó em sua própria tabela de vizinho.
Antes de um pacote de enlace descendente ser encaminhado para o próximo salto, a camada de NET checa se este não é mais antigo do que NET_Downlink_Life_Expectancy. Se for mais antigo, então será apagado.
Sei por qualquer razão, o próximo nó não puder ser atingido (após as novas tentativas de camada de LLC) , a mensagem tem que ser enviada de volta para o mestre de célula pelo percurso de enlace ascendente. Esta mensagem é chamada uma mensagem de enlace interrompido. Uma mensagem de enlace rompido é composta por:
• A mensagem de enlace descendente original.
• 0 endereço de destino final pretendido.
• A ID de quadro de NET da mensagem de mensagem de enlace descendente.
• Uma nova ID de quadro de NET para o enlace interrompido.
• Os endereços do enlace faltando.
Será tarefa do mestre de célula encontrar um outro percurso, levando em consideração mudanças que tenham ocorrido nesse meio tempo. O mestre de célula então reenviará a mensagem de enlace descendente, se um percurso para o destino ainda estiver disponível.
Não há um reconhecimento no nível de camada de rede. Se o usuário do protocolo quiser estar seguro que esta mensagem de enlace descendente atingiu o destino final, ele terá que requisitá-la na camada de aplicativo.
Conforme citado mais tarde, a confirmação de registro de célula e a notificação de saída de célula são casos especiais de pacotes de enlace descendente os quais não geram um enlace interrompido.
Uma mensagem de difusão é iniciada apenas no nível de mestre de célula. Todos os pontos finais conectados à célula devem receber a mensagem de difusão. De modo a simplificar esta operação pesada em uma célula grande, o protocolo não garante que a mensagem seja entregue para 100% dos pontos finais e não prove um reconhecimento no nível de camada de rede. As camadas superiores devem gerenciar uma repetição da mensagem para aqueles que não a tenham recebido. Isto pode ser feito pelo endereçamento da mensagem para cada ponto final remanescente por um percurso de enlace descendente comum. A camada de rede não informa às camadas superiores quais pontos finais foram alcançados (se este fosse o caso, a camada de rede procederia para a repetição de si mesma).
A técnica de difusão é baseada no fato que cada ponto final repete a mensagem de difusão um Number_of_Broacast_Transmissions número de vezes, e cada ponto final pode receber a difusão de qualquer ponto final. Para uma mensagem de difusão enviada pelo mestre de célula, um ponto final receberá tantas réplicas quantos vizinhos tiver; este mecanismo permite uma boa cobertura da célula.
Note que o mestre de célula nunca deve aceitar uma mensagem de difusão, já que ele sempre as gera.
Um mecanismo de filtro é implementado no nível de camada de rede para o envio apenas uma vez da mensagem de difusão para a camada de aplicativo e também para se encaminhá-la uma vez. Um número de mensagem de difusão (NET FID) está contido no cabeçalho de NET para remoção de mensagens que já tenham sido recebidas (o mesmo mecanismo que na camada de LLC) . Com esta detecção de duplicação, a difusão não será repetida infinitamente na célula.
A detecção de duplicação funcionará desde que haja menos difusões sendo encaminhadas na célula do que há espaços na tabela de detecção de duplicação. Isto normalmente seria o caso se a rede fosse usada apropriadamente. Como uma salva-guarda, um mecanismo de expiração foi adicionado. Na inicialização da rede, o mestre de célula acessa o número de hiperquadro (HFN) atual e o insere no cabeçalho de NET. Quando um ponto final na célula recebe esta difusão, ele sempre deve aceitá-la (após checar se não é uma duplicação) , mas apenas a retransmite se a difusão não for antiga demais, por uma comparação do HFN contido no cabeçalho com o HFN atual. 0 tempo de vida máximo de uma difusão na célula é NET_Broadcast_Life_Expectancy.
A camada de NET oferece um serviço não de duplicação para:
• Caminho de enlace ascendente
o Enlace ascendente (com ou sem lista de vizinho)
o Lista de vizinho
o Enlace interrompido
o Notificação de falta
• Difusão
Notificações de difusão e de falta podem ser retransmitidas usando-se vários percursos na rede. Esta redundância contribui para uma melhor qualidade de entrega de imagem. Mas também pode aumentar drasticamente a quantidade de tráfego. Para outras mensagens usando um esquema de modulação e de codificação de roteamento de enlace ascendente, uma duplicação também acontece, mas menos freqüentemente. Note que o percurso de enlace descendente não é concernido aqui, já que não pode ser duplicado. Usar este recurso de detecção de duplicação com mensagens de enlace descendente mesmo degradará as performances do serviço.
Para se evitar encaminhar a mensagem recebida várias vezes para a camada de API ou para o próximo ponto final, cada mensagem transmitida tem um número de identificação de NET, NET FID ou NET OID. Devido a este número, a camada de NET sabe se o pacote já foi recebido. Caso isto aconteça, o pacote será descartado.
Em cada recepção de uma mensagem, o número de mensagem (NET FID ou OID) e o endereço de remetente são escritos em uma tabela dedicada denominada a tabela de duplicação de NET (veja, por exemplo, a presente Figura 56) . Esta tabela contém as propriedades das NET_EP_Duplication_Table_Size últimas mensagens e é gerenciada como um buffer de FIFO. Se a tabela estiver cheia quando uma nova mensagem chegar, a entrada mais antiga da tabela será lançada para fora, conforme a nova for introduzida na tabela. Se a nova entrada for idêntica a uma outra entrada na tabela, isto indicará que uma mensagem em duplicata foi recebida. Neste caso, a cópia mais antiga é removida da tabela, conforme a nova for introduzida na tabela. Desta forma, a informação permanecerá mais tempo na tabela.
0 tamanho de tabela de duplicação de mestre de célula pode ser estendido para NET_CR_Duplication_Table_Size. Isto assegurará uma melhor filtração antes do encaminhamento de mensagens para a camada de API, principalmente útil para notificações de falta que podem ser muito numerosas em um período de tempo curto. Para uma difusão (vindo do mestre de célula), o campo de endereço de remetente deve ser regulado para zero. Para uma notificação de falta, o endereço de remetente deve corresponder ao endereço de remetente original especificado no campo de ORG. No caso em particular de um enlace interrompido, o endereço de remetente é especificado no campo de BRKS. Se o nó perder sincronização, comutar para uma outra célula ou experimentar uma falta de potência (isto pode ser feito na ativação), a tabela de duplicação deverá ser limpa.
Com referência a uma lista de vizinho, se o conhecimento da vizinhança a um salto for suficiente para um ponto final, este não será o caso para o mestre de célula. Este tem que conhecer o conteúdo da célula para a computação dos percursos de enlace descendente. Portanto, todos os pontos finais devem enviar regularmente sua lista de vizinho de NET usando uma mensagem de enlace ascendente.
A lista de vizinho é gerada a partir da tabela de vizinho de NET. Ela consiste nos NET_Nb_of Endpoints_Neighbor_List melhores pais, isto é, pais com SYNC_Merit mais baixo, representado por seus endereços de MAC. Os endereços de ponto final são classificados, o melhor aparecendo primeiro na lista. Esta informação é suficiente para que o mestre de célula roteie pacotes para qualquer ponto final específico.
Como uma opção, se o número de pais presentes na tabela de vizinho for inferior a NET_Nb_of Endpoints_Neighbor_List, a lista de vizinho poderá ser completada com os melhores irmãos (se eles forem válidos para roteamento de pacotes). Contudo, o algoritmo de percurso de enlace descendente deve ser inteligente o bastante para detectar um percurso circular.
Apenas vizinhos sincronizados e registrados da célula podem ser membros da lista de vizinho.
A primeira lista de vizinho é enviada NET_Neighbor_List_First_Time após o ponto final se tornar sincronizado com uma célula para uma partida a quente, e NET_Neighbor_List_Min_Period para uma partida a frio.
As listas de vizinho devem ser atualizadas toda vez que um ponto final for removido da lista ou um novo ponto final for adicionado à lista. As listas de vizinho então são enviadas em um período de NET_Neighbor_List_Min_Period, se uma mudança tiver ocorrido no período prévio. Se um ponto final mudar de nível, isto deve criar um indicador tipo de flag que disparará a transmissão de uma lista de vizinho no fim do período atual. Se um ponto final sofrer uma comutação de célula, então, ele deve estar em uma partida a frio em sua nova célula e deve aplicar o processo correspondente de x~egistro.
Se uma mudança como essa não ocorrer, as listas de vizinho serão enviadas com um período de NET_Neighbor_List_Max_Period.
Um tempo de randomização de + 20% deve ser adicionado a estes períodos e tempos para se evitarem colisões repetitivas.
O mestre de célula é o único ponto final que pode inicializar uma mensagem de difusão e ao mesmo tempo o único que não pode recebê-la. Deve indicar no cabeçalho de NET o número de hiperquadro (HFN) atual no momento da criação.
Parte dos recursos vantajosos do presente assunto de protocolo se refere a um mecanismo de roteamento de enlace descendente. Em particular, a comunicação de enlace descendente representa uma transmissão a partir da cabeça da rede para um único nó na rede de malha. Contudo, o ponto é descobrir um nó que pudesse estar em qualquer lugar, mas o qual seja capaz de ser acessado no tempo mais curto.
O que vem a seguir se dirige mais particularmente a uma funcionalidade de relê de célula em relação a uma tabela de roteamento. Para a realização de uma comunicação de enlace descendente, o mestre de célula (ou relê) precisa ter recebido um primeiro número mínimo de listas de vizinho de modo a computar o melhor percurso para se alcançar o destino.
Como todo ponto final na célula é suposto como tendo enviado uma informação de seus melhores pais, o mestre de célula tem o conhecimento para alcançar qualquer ponto final na célula. Ele apenas tem que dispor a informação que ele recebe dentro de uma tabela de roteamento. Esta tabela de roteamento é atualizada a cada vez em que uma nova lista de vizinho (ou mensagem de enlace interrompido; veja a seção dedicada) é recebida.
Devido ao fato de cada ponto final conhecer seus pais, o mestre de célula pode construir todos os caminhos possíveis entre qualquer ponto final e ele mesmo (isto de fato é limitado pelo número de pais na lista de vizinho, mas provê caminhos possíveis suficientes sem se sobrecarregar o mestre de célula com dados demais a coletar e processar). Os pais nas listas de vizinho são providos em ordem, começando a partir do melhor. O melhor caminho pode ser determinado ao se escolher o primeiro pai na lista começando a partir do destino final até o mestre de célula.
A tabela se moverá permanentemente; portanto, o algoritmo precisa checar se em cada salto da criação, o caminho não vai através do mesmo nó. Isto poderia levar, caso contrário, a um laço infinito ou a um percurso circular. Se o percurso atingiu esse caso, o algoritmo deverá ir de forma reversa no caminho e tentar os pais alternativos. Se nenhum caminho for encontrado, a camada de NET destruirá o pacote e reportará uma falha para a camada de API. Se houver um problema devido a um enlace interrompido ou um caminho circular, esta técnica não garantirá que o novo caminho encontrado seja o segundo melhor, mas assegurará que encontrará um caminho, se houver um.
A cada vez em que o mestre de célula receber uma lista de vizinho atualizada, ele a usará para atualizar sua tabela de roteamento. Deve ser notado que o mestre de célula apenas precisa substituir a entrada correspondente na tabela, sem recomputar coisa alguma.
Quando o mestre de célula precisa enviar uma mensagem de enlace descendente para um ponto final, ele seleciona o melhor caminho e menciona todas as etapas (endereços de nó) do caminho no cabeçalho de rede. Então, ele envia a mensagem para o primeiro ponto final do caminho, e este a encaminhará para o segundo e assim por diante, até o destino final ser alcançado. Todo nó presente na tabela de roteamento pode ser selecionado para roteamento.
Finalmente, se nenhuma mensagem de um ponto final tiver sido recebida por NET_Endpoint_TimeOut, o ponto final deverá ser apagado da tabela, bem como os caminhos através dele. A camada de API também pode requisitar a partir da camada de NET a remoção de um nó específico da tabela.
A presente Figura 57A é um exemplo de uma computação de caminho de enlace descendente para se alcançar o ponto final 10. Os 3 melhores pais são mencionados nas listas de vizinho. Algum ponto final que não tenha 3 pais coloca seus irmãos com caminhos alternativos. Os vizinhos de cada ponto final são aqui classificados por seu SYNC_Merit. O caminho gerado é: 10 ← 8 ← 7 ← 2 ← CM.
Uma mensagem de enlace descendente segue o caminho
indicado pelo mestre de célula, mas, devido ao possível atraso entre a atualização de tabela de roteamento e este pacote de enlace descendente, a configuração de rede pode ter alguns pontos finais que não podem ser mais alcançáveis (falha de potência, comutação de célula, obstáculos...). Quando a camada de LLC reporta uma falha na transmissão da mensagem para o próximo destino, a camada de rede deve enviar de volta para o mestre de célula um enlace interrompido. Se, devido a uma limitação de hardware, não houver espaço na memória para a alocação do enlace interrompido no buffer de mensagem subindo, este deverá ser destruído.
Quando o enlace interrompido chega ao m camada de eletrodo, este deve atualizar sua tabela de roteamento pela remoção do enlace. O enlace descendente então é reenviado se o caminho ainda existir. Este mecanismo de enlace interrompido não se aplica à confirmação de registro de célula ou à notificação de saída de célula; para detalhes, veja a seção de gerenciamento de tamanho de célula aqui.
A presente Figura 57B é uma tabela de roteamento de CR para um roteamento de enlace descendente de exemplo. Quando o número de entradas na tabela de roteamento muda agrupado, o mestre de célula atualiza seu indicador de tamanho de célula de acordo com a presente Figura 57C, e prove esta informação para a camada de MAC. A camada de MAC indicará esta informação em seu cabeçalho e a propagará através da célula. Quando a célula está cheia, isto é, quando o CSI assume seu valor máximo, nenhum ponto final pode requisitar se unir à célula.
Quando a tabela de roteamento atinge NET_Max_Nb_of_EPs entradas, a tabela e a célula são consideradas cheias. Neste caso, toda nova lista de vizinho que chegue ao mestre de célula deve ser usada para se encontrar um caminho para o envio de uma notificação de saida de célula de NET para este nó e, então, apagada. 0 nó que receber esta notificação de saída de célula de NET deve reconhecer o pacote na camada de MAC e deixar a célula após um par de intervalos de tempo (para se garantir que o reconhecimento foi recebido de forma bem sucedida).
A notificação de saída de célula de NET é um caso em particular de uma mensagem de enlace descendente sem uma carga útil. Deve ser tratado como uma mensagem de enlace descendente, exceto pelo fato de nenhuma mensagem de enlace interrompido dever ser enviada se um enlace for interrompido no caminho. Isto é justificado pelo fato de o mestre de célula ter destruído toda a informação relativa a este ponto final e, portanto, não ser capaz de encontrar um caminho alternativo. Note que a notificação de saída de célula de NET também pode ser usada pelo software de gerenciamento superior para supressão do ponto final selecionado em uma célula. A confirmação de registro de célula de NET também não deve disparar um enlace interrompido se a mensagem falhar em ser entregue. A razão para isto é que o processo de registro de célula tem seu próprio mecanismo de nova tentativa o qual lida com essas falhas. Quando o mestre de célula recebe uma notificação de saída de célula, ele deve remover o ponto final correspondente de sua tabela de roteamento e atualizar seu indicador de tamanho de célula.
A tabela da presente Figura 57D resume as ações na camada de NET de mestre de célula, quando a tabela de roteamento está cheia ou quando um nó não está na tabela de roteamento.
O que vem a seguir se refere mais particularmente a um transporte de notificação de falta e à área funcional de registro de célula de acordo com o presente assunto. Conforme é adicionalmente explicado em relação à seção de camada de MAC, um EP pode ouvir, no nível de MAC, que um vizinho experimenta uma falta de potência. Quando este evento ocorre, a camada de MAC indica isso para a camada de Net, com a ID de falta e o tempo quando a mensagem foi recebida como parâmetros. Como uma conseqüência, a camada de Net deve construir uma mensagem de falta de Net, com todos estes parâmetros (endereço de vizinho, ID de falta e tempo de falta), e enviá-la para o relê de célula como uma mensagem de enlace ascendente normal. Quando a mensagem de falta de NET atinge o relê de célula, a mensagem é dada para a camada de API.
Quando um ponto final não é registrado em NET, a camada de API não pode enviar qualquer pacote. A RF LAN deve informar à camada de API quando o ponto final se torna registrado ou deixa de estar registrado (este último caso acontece quando o ponto final retorna para a fase de descoberta ou comuta de célula) . Note que o mestre de célula sempre é considerado registrado em NET.
Uma vez que o ponto final seja registrado em NET, a camada de API está autorizada a se comunicar e pode começar seu próprio processo de registro.
Quando um ponto final comuta para uma outra célula, as camadas de NET e de API precisarão se registrar junto a esta nova célula. A camada de NET informa primeiramente à camada de API que ela não está mais registrada em uma célula e não pode enviar pacotes. O processo a seguir é similar à conexão a uma célula a partir da fase de descoberta.
O protocolo Linknet será implementado em uma arquitetura que terá uma capacidade de armazenamento limitada. Assim, há uma probabilidade não desprezível de a memória alocada para salvamento de mensagens, antes de serem enviadas, poder estar cheia. A cada vez em que a camada de API pede para enviar uma mensagem, a camada de NET confirma ou recusa a requisição. Isto significa que a camada de NET pode destruir o pacote a enviar e reportar uma falha para a camada de API. A camada de API então deve estar encarregada de postergar sua requisição e manter o pacote em sua própria memória.
A camada de NET de mestre de célula também pode reportar uma falha para a camada de API, se o caminho até o destino não puder ser computado ou se o destino não estiver na tabela de roteamento. Com respeito ao quadro de NET, deve ser entendido que a mensagem de rede é dividida em duas partes:
• O cabeçalho de rede contém toda a informação necessária para roteamento da mensagem de rede a partir da fonte até o destino. Ele é dividido em duas partes, as respectivas seções comum e dinâmica.
• 0 corpo de rede contém a mensagem a transferir para a camada de API.
A presente Figura 58 ilustra todos os campos que podem estar presentes no nível de NET. O campo e as diferentes estruturas de mensagem são descritas em outro lugar aqui.
Na Seção Comum do cabeçalho de rede, há os aspectos a seguir, com a presente Figura 5 9 provendo uma tabela a qual apresenta várias facetas referentes ã informação de tipo de quadro de NET:
LV, Versão de Camada:
A versão da camada de rede
FT, Tipo de Quadro:
O tipo de quadro de rede.
Na Seção Dinâmica do cabeçalho de rede, há os aspectos a seguir, alguns dos quais não aparecendo em toda mensagem (daí a natureza dinâmica desta seção de cabeçalho). Eles são descritos aqui em termos gerais, com outros detalhes dos vários tipos de mensagens discutidos aqui em outro lugar.
ORG, Remetente original:
O endereço do remetente original da mensagem. FID, ID de quadro:
O número de mensagem de rede dado pelo remetente original. PL, comprimento de caminho:
O número de endereços no campo de caminho. PATH :
Endereços dos próximos destinos para a mensagem.
Para um enlace descendente, o caminho inteiro é mencionado. Em cada salto, o endereçado remove seu próprio endereço do caminho. RSD, Reservado:
Não usado no momento. Este campo deve ser regulado para 0.
NBN, número de vizinhos:
Número de vizinhos do ponto final. NA, endereço de vizinho:
Endereço do vizinho em relação às propriedades mencionadas.
BRK S, remetente de enlace interrompido:
O endereço de remetente da transmissão de enlace interrompido.
BRK D, destino de enlace interrompido:
O endereço de destino da transmissão de enlace interrompido.
HFN, número de hiperquadro:
0 campo de HFN se refere ao número de hiperquadro de MAC quando o mestre de célula inicializa a difusão. DW FD, destino final:
O destino final para que a mensagem de enlace descendente não recebida era pretendida. Concerne à mensagem de enlace interrompido.
DW FID, ID de quadro de enlace descendente;
O ID de quadro de NET da mensagem de enlace descendente não recebida. Concerne à mensagem de enlace interrompido. OID, ID de falta:
O número de falta do ponto final o qual experimentou uma falha de potência.
OT, tempo de falta:
O tempo no qual o ponto final experimenta a falta de potência. É um formato de ITP.
Com referência adicional ao corpo de quadro e a uma PDU de aplicativo relacionada (APIPDU) , ele contém uma informação relativa à camada de aplicativo. É a mensagem final que o protocolo entrega para a camada de aplicativo. Ela pode ser entregue para o ponto final de destino ou para o relê de célula.
O que vem a seguir se refere mais particularmente a mensagens de NET. O comprimento de cabeçalho de NET para uma mensagem de enlace ascendente é de 8 bytes, conforme representado. pela presente Figura 60. O pacote de acompanhamento (trace) é usado para fins de depuração de erro. Contudo, o comprimento de cabeçalho de NET para um caminho de enlace descendente é de 5 bytes mais 4 bytes vezes o comprimento de caminho, conforme representado pela presente Figura 61. Isto não inclui o próximo destino o qual é passado em um parâmetro a ser colocado no cabeçalho de MAC. O campo ORG não é incluído, uma vez que todas as mensagens de enlace descendente se originam no relê de célula. Adicionalmente, pela presente Figura 61, HOP-N é o endereço do destino final da mensagem de enlace descendente, enquanto HOP-I é o endereço do próximo destino da mensagem de enlace descendente. Quando um ponto final quer enviar sua lista de vizinho para o mestre de célula, ele a insere na localização do corpo de quadro. A requisição de registro de célula usa o mesmo formato, mas com um tipo de quadro diferente.
Conforme representado pela presente Figura 62, a lista de vizinho ou o comprimento de requisição de registro de célula no nível de NET é de 21 bytes.
É uma combinação de uma mensagem de enlace ascendente e de uma mensagem de lista de vizinho. Conforme representado pela presente Figura 63, o comprimento de cabeçalho de NET para um enlace ascendente com uma mensagem de lista de vizinho é de 21 bytes.
Conforme representado pela presente Figura 64, o comprimento de cabeçalho de NET de difusão é de 4 bytes. 0 campo de HFN se refere ao número de hiperquadro de MAC quando o mestre de célula inicializa a difusão.
Quando o mestre de célula quer rejeitar um nó da célula, ele envia uma notificação de saída de célula para este nó. O comprimento de mensagem é de 5 bytes mais 4 bytes vezes o comprimento do caminho. Conforme representado pela presente Figura 65, a confirmação de registro de célula usa o mesmo pacote com um tipo de quadro diferente para confirmação para um nó que ele é aceito na célula.
Se durante uma transmissão de enlace descendente um ponto final não conseguir encaminhar a mensagem para o próximo ponto final, então, um enlace interrompido será reportado. A mensagem de enlace interrompido consiste no endereço dos dois EPs definindo o enlace interrompido e na mensagem original (a qual não foi armazenada no mestre de célula). Esta mensagem de enlace interrompido será usada pelo mestre de célula para a atualização de sua tabela de roteamento e para computação de um novo melhor caminho. Conforme representado pela presente Figura 66, o comprimento de cabeçalho de NET da mensagem de enlace interrompido é de 18 bytes.
Se um EP ouvir uma mensagem de falta (em um nível de MAC) a partir de um EP o qual experimenta uma falta de potência, ele estampará no tempo a notificação de falta com seu tempo local usando um formato de ITP. Deve criar, então, uma mensagem de falta (NET) e enviá-la para o mestre de célula da mesma forma como uma mensagem de enlace ascendente. O OID é o mesmo que na mensagem de falta de MAC original. E o campo de OT é a estampa de tempo de ITP da recepção da notificação de falta (MAC). Conforme representado pela presente Figura 67, o comprimento de cabeçalho de NET da mensagem de falta é de 11 bytes.
A notificação de saída de célula é enviada por um ponto final imediatamente antes de deixar uma célula. Isto informa ao mestre de célula que este ponto final pode ser removido da tabela de roteamento e o CSI ajustado de modo conforme. Como representado pela presente Figura 67, o comprimento de NET de notificação de saída de célula é de 8 bytes.
Com referência às interfaces e aos serviços de NET, será apreciado que a camada de Rede propõe uma variedade de serviços diferentes, conforme ilustrado em detalhe significativo pelo assunto incluído na presente Figura 69.
A camada de rede está encarregada do roteamento. A camada de rede conhece a vizinhança a 1 salto e pode tomar uma decisão quanto ao caminho a tomar para o encaminhamento de um pacote na direção de enlace ascendente ou de enlace descendente. Se a mensagem tiver chegado ao seu destino, em um ponto final ou um relê de célula (mestre de célula), ela a proporcionará para a camada de API.
O que vem a seguir se refere mais particularmente a uma funcionalidade do presente assunto de protocolo com referência às requisições de net.
Com um objetivo de enviar uma mensagem para um destino, NET_Request_Send_Mono_Data, há o uso de argumentos de entrada: APIPDU, endereço de destino. A operação pode ser descrita como a camada de API pedir à camada de NET para enviar uma mensagem para o mestre de célula. Para o mestre de célula: a camada de API pede à camada de NET para enviar uma mensagem para um ponto final em particular.
Com um objetivo de enviar uma mensagem de difusão para a célula inteira, até o relê de célula apenas, NETRequestSendBroadcast, há o uso dos argumentos de entrada requisitados: APIPDU. A operação pode ser descrita como a camada de API requisitando que a camada de NET envie uma mensagem para a célula inteira.
Com um objetivo de enviar uma mensagem de RITP para a célula inteira, até o relê de célula apenas, NET_Request_Send_ITP, não há o uso de quaisquer argumentos de entrada. A operação pode ser descrita como a camada de API requisitando que a camada de NET envie uma mensagem de ITP para a célula inteira. Esta requisição segue a mesma abordagem que uma NET_Request_Send_Broadcast, exceto pelo fato de não haver uma NETPDU. A camada de MAC estará encarregada da estampa de tempo da mensagem.
Com um objetivo de atualizar o RITP da camada de MAC, até o relê de célula (mestre de célula) apenas, NET_Request_Update_ITP, há o uso dos argumentos de entrada requisitados: estampa de tempo de ITP absoluta. A operação pode ser descrita como a camada de API requisitando que a camada de MAC atualize seu RITP com um novo valor de ITP.
Esta requisição tem prioridade em relação a todas as outras requisições e é encaminhada diretamente para a camada de LLC.
Com um objetivo de medir o nível de interferência médio e sua função de autocorrelação no tempo, NET_Request_Environment_Analysis_Auto-Correlation, há o uso de argumentos de entrada: Número de canal, Número de amostras. A operação pode ser descrita como uma requisição que é encaminhada diretamente para a camada de LLC.
Com um objetivo de medir o nível de interferência médio em três canais especificados e sua função densidade de probabilidade, NETRequest_Environment_Analysis_PDF, há o uso dos argumentos de entrada requisitados: Números de canal (3), valor máximo de contador. A operação pode ser descrita como uma requisição que é encaminhada diretamente para a camada de LLC.
Com um objetivo de proporcionar à camada de MAC a informação quanto a se uma célula está autorizada ou não, NET_Request_Cell_Authorization, há o uso dos argumentos de entrada requisitados: Endereço de célula e Status de célula. A operação pode ser descrita como uma requisição que é encaminhada diretamente para a camada de LLC.
Com um objetivo de proporcionar a remoção de um nó da tabela de roteamento, até o relê de célula (mestre de célula) apenas, NET_Request_Remove_Node, há o uso dos argumentos de entrada requisitados: Endereço de nó. A operação pode ser descrita como a camada de API poder informar às camadas de Linknet que um nó não pertence mais à célula. A camada de NET assim removerá o nó da tabela de roteamento e atualizará o número de ponto final na célula.
Com um objetivo de enviar uma notificação de saída de célula para um nó, até o relê de célula (mestre de célula) apenas, NET_Request_EjectNode, há o uso dos argumentos de entrada requisitados: Endereço de nó. A operação pode ser descrita como uma requisição que a camada de API pode requisitar à camada de NET para obter um nó fora da célula. A camada de NET então enviará uma notificação de saída de célula para este nó e o removerá da tabela de roteamento.
O que vem a seguir se refere mais particularmente à funcionalidade do presente assunto de protocolo com referência a confirmações de NET.
Com um objetivo de responder a NET_Request _Send_Mono_Data, NET_Request_Send_Broadcast e NET_Request_Send_ITP, NET_Conf i rmat i onS end_Mono_Dat a, NETConfirmation_Send_Broadcast e NET_Confirmation_Send ITP, há o uso de argumentos de saída requisitados: Status. A operação pode ser descrita como se proporcionar o status da requisição. Pode ser uma mensagem transmitida, uma mensagem com falha ao ser transmitida, buffer cheio, caminho até o destino não encontrado ou quaisquer outros tipos de erros.
Com um objetivo de responder a NET_Request_Update_ITP, até o relê de célula apenas, NET_Confirmation_Update_ITP, há o uso de argumentos de saída requisitados: Status. A operação pode ser descrita como se proporcionar o status da requisição.
Com um objetivo de responder a NET_Request_Environment_Analysis_Auto-Correlation, NETConf irmat ion_Environment_Analysis_Auto-Correlat ion, há o uso de argumentos de saída requisitados: RSSI médio e valores de função de autocorrelação de RSSI. A operação pode ser descrita como um encaminhamento de LLC_Conf i rmat ion_Envi ronment_Analys i s_Auto - Corre 1 at ion a partir da camada de LLC para a camada de API.
Com um objetivo de responder a NET_Reque s t_Env.i r onment_Analy s i s_PDF, NETConfirmation_Environment_Analysis_PDF, há o uso de argumentos de saída requisitados: valores de PDF de RSSI para os três canais requisitados (3 χ 24 valores) . A operação pode ser descrita como um encaminhamento de LLC_ Confirmation_Environment_AnaIysis_PDF a partir da camada de LLC para a camada de API.
Com um objetivo de responder a NET_Request_Cell_Autorization,
NET Confirmation_Cell_Authorization, há o uso de argumentos de saída requisitados: Status. A operação pode ser descrita como um encaminhamento de LLC_Confirmation_Cell_Authorization a partir da camada de LLC para a camada de API.
Com um objetivo de responder a NET_Reque s t_Remove_Node, até o relê de célula (mestre de célula) apenas, NET_Confirmation_Remove_Node, há o uso de argumentos de saída requisitados: Status. A operação pode ser descrita como se proporcionando o status da requisição.
Com um objetivo de responder a NET_Eject_Remove_Node, até o relê de célula (mestre de célula) apenas, NET_ConfirmationEject Node, há o uso de argumentos de saída requisitados: Status. A operação pode ser descrita como se proporcionando o status da requisição.
O que vem a seguir se refere mais particularmente à funcionalidade do presente assunto de protocolo com referência às Indicações de NET.
Com um objetivo de indicar para a camada de API que uma mensagem foi recebida para ela e prover esta mensagem, NET Indication_Received, há o uso de argumentos de saída: APIPDU. A operação pode ser descrita como quando uma mensagem atinge seu destino final, a camada de NET proporcionar a mensagem para a camada de API.
Com um objetivo de atualizar o ITP da camada de API, até o relê de célula apenas, NET_Indication_ITP_Update, há o uso de argumentos de saída: estampa de tempo de ITP absoluta. A operação pode ser descrita como um encaminhamento direto de LLC_Indication_ITP_Update a partir da camada de LLC para a camada de API. Esta indicação tem prioridade em relação a todas as outras indicações.
Com um objetivo de indicar para a camada acima o estado de NET, NET_Indication_State, há o uso de argumentos de saída requisitados: Estado e Endereço de célula. A operação pode ser descrita como a camada de NET indicar para a camada de API se o ponto final está sincronizado e registrado junto a uma célula. Uma vez que esteja, a camada de API obtém os direitos de usar a rede.
Com um objetivo de indicar para a camada de API que uma notificação de falta foi recebida, até o relê de célula apenas, NET_Indication_Outage Received, há o uso de argumentos de saída requisitados: endereço de EP, ID de falta e tempo de falta. A operação pode ser descrita como quando um relê de célula (ou mestre de célula) recebe uma notificação de falta através da RF LAN, ele deve proporcioná-la à camada de API. A camada de API se reportará ao agente de coleta usando o formato C12.22.
O que vem a seguir se refere a uma análise de estabilidade do algoritmo de compensação de deriva de cristal e indica como computar os coeficientes de filtro. Para se discutir o comportamento do processo de correção de deriva, a presente Figura 70 provê um modelo diagramático do laço de controle de retorno.
Com referência mais específica a essa Figura 70, TS_Length_Cell é o comprimento de intervalo de tempo padrão da célula, conforme visto a partir do ponto final (isto é, conforme medido na própria referência de tempo do ponto final). Qualquer discrepância entre a referência de tempo de ponto final e a referência de tempo de célula resultará em uma diferença entre TSJLength e TS_Length_Cell.
Considerando-se a reação de laço a uma mudança súbita em TS_Length_Cell, podem-se ajustar os coeficientes de filtro para se tornar esta resposta bem comportada.
Para fins analíticos, a presente Figura 71 é uma simplificação do diagrama da presente Figura 70. Para essa simplificação, o laço representado pode ser descrito pelas equações de recorrência a seguir:
<formula>formula see original document page 318</formula> Conforme será entendido por aqueles de conhecimento comum na técnica, as transformadas Z destas equações são:
<formula>formula see original document page 319</formula>
Resolvendo para X2 e, então, para Tslot:
<formula>formula see original document page 319</formula>
A expressão final para Tsiot é
<formula>formula see original document page 319</formula>
E a função de transferência do laço é:
<formula>formula see original document page 319</formula>
Esta é uma função de transferência de passa baixa de segunda ordem. Para se olhar para o comportamento dinâmico, encontram-se os pólos desta função, escritos aqui na forma padrão:
<formula>formula see original document page 319</formula>
onde:
<formula>formula see original document page 319</formula> Os zeros de
<formula>formula see original document page 320</formula>
Relações simples entre b1, b2 e os pólos da função de transferência são representados por:
<formula>formula see original document page 320</formula>
Uma abordagem simples que economiza tempo para avaliação dos coeficientes de filtro é mapear os pólos da função de transferência discreta no tempo para os pólos da função de transferência de tempo contínua correspondente.
Estes pólos são dados por
<formula>formula see original document page 320</formula>
onde ζ é o fator de amortecimento e ω0 é a freqüência angular do sistema de tempo contínuo equivalente. Estes pólos estão relacionados aos pólos no plano z por z = esr, levando à expressão a seguir para os pólos no plano z:
<formula>formula see original document page 320</formula>
Após isso, podem-se escrever os coeficientes de função de transferência em termos dos parâmetros de sistema de tempo contínuo:
<formula>formula see original document page 320</formula>
Resolvendo-se para AeB, tem-se:
<formula>formula see original document page 320</formula>
O parâmetro de projeto relevante é o número de amostras usadas para computação da média (realmente, é um filtro de passa baixa e não uma média) . Isto é definido arbitrariamente como o número de amostras necessárias para se atingir o excesso da resposta em degrau:
<formula>formula see original document page 321</formula>
As equações a seguir são obtidas para a computação dos coeficientes de filtro em termos de Navg amortecimento ζ:
<formula>formula see original document page 321</formula>
Por exemplo, Navg = 16,5 e ζ = 0,7 dão A = 1/16 e B = 0,732 .
A presente Figura 72 ilustra a resposta em degrau desse laço em uma reação a uma mudança no comprimento de intervalo de tempo de célula de 100 ms para 110 ms. 0 sistema atinge um valor estável após em torno de 20 ressincronizações com um excesso esperado de 4,6%. 0 valor padrão a seguir para os parâmetros de camada de MAC podem ser usados para uma modalidade de exemplo preferida:
<formula>formula see original document page 321</formula>
0 uso do atraso de propagação mínimo para a otimização da rede de malha é um outro recurso vantajoso presente regulado. Em uma rede de malha, um método é proposto presentemente para se computar o atraso de propagação entre qualquer nó na rede e o nó de raiz da rede. Este atraso de propagação então é usado como um critério para a seleção do melhor percurso dentre vários na rede.
A estabilidade e a performance da rede de malha são com base na sua capacidade de auto-otimizar e autocurar sua topologia. Esta auto-otimização da rede também é fundamental para o equilíbrio e a limitação do tráfego de rede. Portanto, é importante prover o protocolo com um bom algoritmo de seleção de percurso. O melhor percurso deve ter as propriedades a seguir:
• O melhor percurso deve ter a latência mais curta do 15 transmissor para o receptor.
• O melhor percurso deve minimizar o número de retransmissões.
• O melhor percurso deve causar tão pouca interferência quanto possível.
O presente assunto é para usar o critério de "percurso mais curto" é escolher o melhor percurso dentre vários. O percurso mais curto é definido aqui como o percurso com o atraso de propagação médio mais curto. Uma referência é feita aqui às ilustrações diagramáticas das presentes 2Figuras 73A, 73B e 73C.
Quando uma tentativa de comunicação do nó A para o nó B falha, o nó A retransmite a mensagem uma segunda vez ou tantas vezes quanto necessário para se tornar bem sucedida a transmissão. Para fins práticos, o número de tentativas de retransmissões é limitado a algum valor máximo de modo a se evitar perder tempo em um enlace interrompido. 0 tempo médio gasto para a transmissão de uma mensagem a partir do nó A para o nó B é chamado neste protocolo o atraso de propagação local (LPD) de A para B. É direto estender este conceito para um percurso mais complexo. Por exemplo, o atraso de propagação entre os nós A e D ao longo do percurso ABCD (veja a presente Figura 73A) é a soma dos atrasos de propagação de A para B, de B para C e de C para D.
De modo a se evitar usar memória demais em um nó, cada nó está ciente apenas de seus vizinhos imediatos e, portanto, não pode fazer diretamente a soma de todos os atrasos de propagação por todo o caminho até o nó de raiz. Para se resolver este problema, cada nó na rede computará dois tipos de atrasos: o atraso de propagação local (LPD) e o atraso de propagação global (GPD). Um nó computará o LPD para cada um de seus nós vizinhos na direção da raiz de rede. O GPD de um nó é definido como o atraso de propagação total mais curto do nó todo o caminho até o nó de raiz da rede. Aqui, mais curto significa que há vários caminhos possíveis de um nó até o nó de raiz, e aquele com o atraso de propagação mais curto é selecionado e usado para a definição do atraso de propagação global (GPD) do nó.
Como um exemplo, para a rede ilustrada na presente Figura 73B, o GPD a partir de A até a raiz será:
GPD(A) = Min { [LPD(A,B) + L PD(B,D)], [LPD(A,C) + LPD(C,D)]}
Para se tornar a computação de GPD possível apenas com o conhecimento da vizinhança imediata, a informação de GPD é propagada etapa a etapa a partir da raiz até os nós.
Como um exemplo, para a rede ilustrada na presente Figura 73C, o GPD de A até a raiz será computado desta forma:
<formula>formula see original document page 324</formula>
onde GPD(A) é o atraso de propagação total de A até a raiz e GPD(B) é o atraso de propagação total de B até a raiz.
As operações detalhadas a serem realizadas dentro de um nó, então, são:
• Cada nó mantém um registro de todas as tentativas de comunicação com cada um dos nós na direção da raiz da rede e computa uma taxa de sucesso de comunicação estatística com cada um destes nós.
• A partir desta taxa de sucesso de comunicação, um atraso de propagação local médio é computado para cada enlace a um salto.
• A partir do GPD dos nós vizinhos, o nó computará o atraso de propagação total ao longo de cada caminho até o nó de raiz e selecionará o valor mais curto para a definição de seu próprio valor de GPD.
· O nó então tornará seu valor de GPD acessível a todo nó em seu alcance pela atualização de seu cabeçalho de mensagem.
Os detalhes matemáticos desse presente assunto podem ser destacados conforme se segue. Nós consideraremos um enlace de salto único (ponto a ponto) ; em um ambiente sem colisão, o atraso de propagação médio D será dado por:
D=Td,
onde Td é o tempo necessário para que um pacote viaje do transmissor para o receptor.
Considerar o efeito de colisões sobre o atraso de propagação médio significa considerar todos os casos possíveis: nenhuma colisão ocorreu, uma colisão ocorreu, duas colisões, e assim por diante. 0 atraso de propagação será dado por:
<formula>formula see original document page 325</formula>
Aqui, Pé a taxa de pacote de sucesso e Tr é o tempo de espera entre retransmissões.
Para se manter a derivação adicional simples, pode-se assumir que este tempo é constante. A expressão pode ser fatorada desta forma:
<formula>formula see original document page 325</formula>
Substituindo-se a soma da série geométrica:
<formula>formula see original document page 325</formula>
Descobre-se uma expressão simples para o atraso de propagação médio em um enlace único de ponto a ponto:
<formula>formula see original document page 325</formula>
Devido ao ambiente mudando constantemente, este valor de atraso de propagação médio preferencialmente deve ser atualizado após cada uso de qualquer dado enlace. A expressão do atraso de propagação médio como uma função do número de utilização de enlace η é escrito conforme se segue:
<formula>formula see original document page 325</formula>
Este atraso pode ser dividido em uma parte estática e uma parte dinâmica:
D(n)- Td + TrDr (n)
onde Dr (n) é a parte do atraso de propagação devido a retransmissões, normalizado para o tempo de espera de retransmissão. Dr (n) está diretamente relacionado à taxa de sucesso de pacote por:
<formula>formula see original document page 326</formula>
Após cada tentativa de transmissão de pacote em um dado enlace, a taxa de sucesso de pacote P(n) é atualizada com uma média móvel, conforme mostrado abaixo:
<formula>formula see original document page 326</formula>
onde Nav é o número de transmissões usadas para a computação da média e PS (n) é o sucesso / a falha na tentativa η:
<formula>formula see original document page 326</formula>
A partir da equação de atualização de PSR, pode-se derivar uma equação para a atualização do atraso de propagação:
<formula>formula see original document page 326</formula>
Expressando o atraso como uma função do PSR,
<formula>formula see original document page 326</formula>
encontramos: <formula>formula see original document page 327</formula>
As equações para atualização do atraso de propagação de qualquer enlace então são:
<formula>formula see original document page 327</formula>
Se uma tentativa de transmissão falhar, nós usaremos a primeira equação; se ela for bem sucedida, nós usaremos a segunda. Isto pode ser estendido facilmente para um percurso de salto múltiplo da forma a seguir:
<formula>formula see original document page 327</formula>
onde a soma é estendida para todos os saltos individuais de um percurso. Quando esta equação é usada para fins de comparação de percursos diferentes, ela pode ser normalizada da forma a seguir:
<formula>formula see original document page 327</formula>
Os benefícios principais incluem: leva a uma seleção de percurso ótima; e pode ser implementado em cada nó com apenas o conhecimento local da vizinhança.
O que vem a seguir se refere ao presente assunto de protocolo referente à operação para gerenciamento de carga de tráfego, particularmente incluindo cenários de resposta envolvendo falhas de transmissão de pacote.
De modo a mais bem portar as presentes regras de
<formula>formula see original document page 327</formula> gerenciamento de tráfego, precisa-se fazer várias hipóteses de simplificação, porque o problema de colisões de RF é extremamente complexo. A questão em mãos não é a mesma que tentar fazer avaliações acuradas de carga de tráfego.
Algoritmos de gerenciamento de carga de tráfego detalhados são estabelecidos na descrição de protocolo em outro lugar aqui.
Para se começar, podem-se analisar as possíveis causas para uma falha de transmissão de pacote e a cura possível correspondente para cada caso, assumindo, em uma primeira etapa, que a causa da falha seja conhecida. Isto considerará a análise do problema de fluxo de tráfego no relê de célula e derivará uma regra de limitação de tráfego simples a partir deste caso especial. Após isso, uma estratégia mais global pode ser destacada, para se lidar com estas falhas através de tempos de espera e retransmissões adequados. Esta estratégia é projetada para a otimização da latência e do ritmo de transferência de enlaces individuais entre nós. Não é projetada para compartilhamento uniforme do tráfego entre diferentes percursos da rede em malha. O gerenciamento de carga proposto impedirá a rede de entrar em colapso, se a demanda exceder à capacidade da rede, mas não substituirá um gerenciamento no nível de aplicação. Espera-se que o gerenciamento de carga na camada de aplicativo disperse o tráfego tão uniformemente quanto possível no tempo e evite requisitar dados demais ao mesmo tempo. Uma sobrecarga de rede de LAN deve permanecer uma situação excepcional.
A presente Figura 74 é uma tabela relativa a vários cenários de causas e soluções de falha de transmissão, pelo presente assunto de protocolo, os quais são adicionalmente comentados aqui.
0 que vem a seguir é com referência em particular ao conjunto de condições de "Causa possivel (1)" da Figura 74. Um desvanecimento de Rayleigh é fortemente dependente da freqüência. Como uma conseqüência, alguns canais terão uma taxa de sucesso de pacote muito melhor do que outros. Isto será particularmente notável com enlaces de longa distância com uma margem de enlace fraco. Não será incomum ver mais de 10 dB de diferença entre link budgets (tabelas que contêm os dados referentes ao cálculo para análise de enlaces) de dois canais. Uma diferença como essa tornará alguns canais usáveis para fins de transmissão de dados., mesmo quando nenhum sinal de interferência intencional estiver presente. Um desvanecimento de Rayleigh é devido a uma interferência de percurso múltiplo e as condições ambientais que tornam um canal ruim variarão no tempo e de nó para nó. Portanto, não é simples excluir estes canais ruins da lista. Mais ainda, os regulamentos de rádio nos Estados Unidos impedem que se faça isso inteiramente; todos os canais devem ser usados da mesma forma. Quando um pacote falha em ser reconhecido, devido a essas condições, a solução é tentar de novo em um outro canal. Não há necessidade de esperar pela próxima tentativa de transmissão neste caso. Um tempo de espera adicional aqui apenas aumentaria a latência do sistema. Em alguns casos extremos, o sistema falhará em transmitir de forma bem sucedida seus pacotes em todos os canais disponíveis. Isto pode ser causado por condições ambientais duras como uma tempestade com raios ou pela presença de uma grande obstrução próximo do ponto final. Esta condição também pode vir de uma perda de sincronização. Neste caso, o ponto final terá que introduzir um tempo de espera significativo e retomar suas transmissões mais tarde, conforme destacado na tabela da presente Figura 74.
O que vem a seguir é com referência em particular ao conjunto de condições de "Causa possível (2)" da Figura 74. A banda de ISM usada pelo presente assunto de protocolo é uma banda compartilhada. Outros usuários da banda interferirão com essas transmissões e alguns pacotes serão perdidos devido a colisões. Obviamente, este fenômeno será mais importante para enlaces de longa distância devido a uma margem de enlace mais fraca. Interferentes podem ser transmissores de potência baixa de banda estreita, saltadores de freqüência ou transmissores de banda larga, de potência alta. A largura de banda de qualquer interferente não obstante será pequena, se comparada com a largura de banda de ISM inteira e, na maioria dos casos, a retransmissão em um canal diferente será suficiente para se evitar a interferência. Como no caso prévio, não há necessidade de esperar por uma tentativa de uma retransmissão. Um tempo de espera adicional aqui aumentaria a latência do sistema. Em alguns casos extremos, o sistema falhará em transmitir de forma bem sucedida seus pacotes para todos os canais disponíveis. Isto pode ser causado por um interferente intencional de potência muito alta próximo o bastante do ponto final para deixar de detectar sua front end de receptor. Neste caso, o ponto final terá que introduzir um tempo de espera significativo e retomar suas transmissões mais tarde, conforme destacado na tabela da presente Figura 74.
O que vem a seguir é com referência em particular ao conjunto de condições de "Causa possível (3)" da Figura 74. Conforme o tráfego gerado pelo presente assunto de protocolo crescer mais alto, colisões internas entre pacotes ocorrerão. Em algum ponto, estas colisões internas serão freqüentes o bastante para degradarem o ritmo de transferência efetivo do sistema. Neste caso, uma transmissão em um outro canal não melhorará a situação, porque todo ponto final segue o mesmo padrão de salto. A partir de um ponto de vista de probabilidade de colisão, o sistema se comporta como se apenas um canal fosse usado. A relação entre probabilidade de colisão e ritmo de transferência efetivo é bem conhecida a partir da teoria de Aloha com intervalo. A teoria clássica lida com o caso em que nenhum interferente intencional externo está presente. Aqui, a situação é mais difícil de analisar, porque nós temos ambos os tipos de colisões no mesmo tipo: colisões internas devido ao tráfego em questão e colisões externas com os outros usuários da banda. Daí, é desejável introduzir um mecanismo de regulagem para desaceleração do tráfego em questão, quando ele crescer acima de algum limite, conforme destacado na tabela da presente Figura 74.
O que vem a seguir é com referência em particular ao conjunto de condições de "Causa possível (4)" da Figura 74. Quando um ponto final não pode lidar com uma mensagem entrando devido a limitações de memória, ele responderá com um reconhecimento negativo e descartará a mensagem recebida. Isto também pode ser causado por um congestionamento de tráfego em um nó remoto da rede. Quando um nó precisa desacelerar seu tráfego, ele responderá com um reconhecimento negativo, quando seu buffer de entrada ficar cheio. Esta condição se propagará etapa por etapa ao longo do percurso de tráfego a montante. O destinatário de um reconhecimento negativo deve tentear um outro destino ou retransmitir após algum tempo de espera, conforme destacado na tabela da presente Figura 74.
O que vem a seguir provê uma discussão com referência a uma análise do fluxo de tráfego de transferência (via upload) no relê de célula, de acordo com o presente assunto de protocolo. O relê de célula é o ponto em que todo o tráfego converge. Se uma paralisação por congestionamento ocorrer, mais provavelmente ocorrerá no relê de célula; portanto, é importante analisar as condições de tráfego neste caso especifico. Apenas a situação de transferência (via upload) é considerada aqui, porque este é o caso relevante para gerenciamento de carga de tráfego. A presente Figura 75 representa de forma diagramática um modelo para a carga de tráfego do presente assunto, no relê de célula, e útil para a referência na presente discussão.
Como a situação real é extremamente complexa, algumas simplificações são desejadas de modo a se caracterizarem mais prontamente algumas regras de gerenciamento de tráfego. Uma hipótese é feita, por exemplo, que o relê de célula (ponto final A na presente Figura 75) apenas pode ouvir as transmissões de pontos finais de nível 2 (pontos finais Bi na Figura 75). Isto é uma hipótese idealizada. Em uma implementação real, transmissões bem sucedidas esporádicas entre os pontos finais de nível 3 e o relê de célula ocorrerão mais provavelmente. Uma hipótese também é feita quando aos pontos finais de nível 2 estarem fora de alcance uns dos outros. Isto parece com uma situação idealizada para pontos finais de nível 2, mas é um pior caso do ponto de vista do relê de célula, porque um ponto final de nível 2 não tem conhecimento do tráfego enviado por seus vizinhos para o relê de célula neste caso. Uma outra presente hipótese simplificadora é que dois pacotes, dois reconhecimentos ou um pacote e um reconhecimento chegando a um receptor no mesmo intervalo de tempo sempre colidirão e resultarão em nada ser recebido. Obviamente, isto é uma hipótese pessimista, mas apenas simulações extensivas permitirão uma modelagem mais acurada do processo de colisão.
A notação a seguir é utilizada para a descrição do fluxo de tráfego:
• R(X,Y,Z) = número médio de pacotes enviados pelo ponto final X, pretendido para o ponto final Y e acima do limite de sensibilidade para o ponto final Z, por intervalo de tempo;
• S(XjYjZ) = número médio de pacotes enviados pelo ponto final X, pretendido para o ponto final Y e recebidos de forma bem sucedida pelo ponto final Zj por intervalo de tempo;
• T(XjYjZ) = número médio de pacotes únicos enviados pelo ponto final Xj pretendido para o ponto final Y e recebidos de forma bem sucedida pelo ponto final Z, por intervalo de tempo (isto é, sem pacotes duplicados);
• U(X,Y,Z) = número médio de reconhecimentos enviados pelo ponto final X, pretendido para o ponto final Y e acima do limite de sensibilidade para o ponto final Z, por intervalo de tempo;
• V(X,Y,Z) = número médio de reconhecimentos enviados pelo ponto final X, pretendido para o ponto final Y e recebidos de forma bem sucedida pelo ponto final Z, por intervalo de tempo.
A densidade de entrada de tráfego total vista pelo relê de célula é a soma das densidades de tráfego geradas por todos os filhos do relê de célula (pontos finais Bi na Figura 75). 0 tráfego total se divide em pacotes de dados e reconhecimentos. O tráfego de dados é dado por:
<formula>formula see original document page 334</formula>
onde B significa o conjunto de todos os pontos finais de nível 2 ,B= [B1, B2, ..., Bn]. A soma se estende por todos os filhos de A (os pontos finais de nível 2) . Os reconhecimentos enviados pelo ponto final Bi e que se pretende que sejam para os filhos de Bi são ouvidos por A e devem ser incluídos no tráfego total enviado por A. Este tráfego de reconhecimento é dado por:
<formula>formula see original document page 334</formula>
onde C significa o conjunto de todos os 3 pontos finais, conforme dado por
<formula>formula see original document page 334</formula>
com a notação Sof (X) {todos os filhos de X) . Para fins de avaliação de probabilidade de colisão, estes dois tipos de tráfego serão tratados da mesma forma. O tráfego total então é R (Β, Ά, Ά) + U (B, C, A) . O ritmo de transferência de pacote de dados no relê de célula é dado por:
<formula>formula see original document page 335</formula>
onde nós introduzimos a taxa de sucesso de pacote para a transmissão de um pacote a partir do ponto final Bi até o ponto final A:
<formula>formula see original document page 335</formula>
0 primeiro termo na expressão da PSR é a probabilidade de todos os outros pontos finais de nível 2 estarem silenciosos quando Bi transmitir seu pacote. Esta probabilidade é dada pela distribuição de Poisson para um "evento zero". A expressão entre colchetes é o valor médio do número de eventos em um único intervalo de tempo. O próximo termo, PSRe(A), é a probabilidade de o pacote de dados ser recebido sem colisão com interf erentes fora da presente rede em questão. Finalmente, Q(A) é a probabilidade de o ponto final estar no estado de recepção quando o pacote chegar. Esta probabilidade é igual a um menos a probabilidade de o ponto final A estar reconhecendo um pacote previamente recebido:
Q(A) = 1-S(B,A,A)
O relê de célula reconhecerá cada pacote recebido, e isto provê uma relação entre o número de pacotes recebidos de forma bem sucedida por Aeo número de reconhecimentos chegando a Bi:
U(A,B1,B1) = S(B1,A,A)
O número de reconhecimentos recebidos de forma bem sucedida por Bi é dado por:
<formula>formula see original document page 336</formula>
onde a taxa de sucesso de reconhecimento, ASR (A, Bi) é introduzida. Esta taxa de sucesso de reconhecimento é dada por:
<formula>formula see original document page 336</formula>
onde é definido que Sof 2 (Bi) = Sof (Sof (Bi)).
A partir do ponto de vista de aplicativo, o tráfego relevante é o número de pacotes recebidos pelo relê de célula após um apagamento dos pacotes em duplicata. Um pacote em duplicata é gerado quando o reconhecimento falha em ser recebido pelo remetente do pacote.. Este número de pacotes únicos deve ser igual ao número de reconhecimentos recebidos de forma bem sucedida pelos pontos finais de nível 2, T (Bi, A, A) =V (A, Bi, Bi).
Segue-se uma relação entre T (Bi, A, A) e R (Bi, A, A) :
T(Bi, A, A) = R(Bi,A,A)PSR(B1, A) ASR(A, Bi)
Nesta equação, PSR(Bi( A) ASR (A, Bi) é a taxa de sucesso para a transmissão do pacote e a recepção do reconhecimento seguinte. Esta é a "taxa de sucesso de pacote" que o ponto final Bi medirá quando tentar enviar seu pacote para o relê de célula. A taxa total de recepção de pacotes não duplicados é obtida pela soma da equação precedente:
T(BiAiA) = V R(Bi} A, A) PSR (B1, A) ASR (AtBl) ,=| O número de reconhecimentos enviados por A para Bi está relacionado à taxa de tráfego por:
<formula>formula see original document page 337</formula>
De uma forma similar, os reconhecimentos recebidos pelo relê de célula, mas pretendidos para os pontos finais de nível 3 também são proporcionais ao tráfego total:
<formula>formula see original document page 337</formula>
A contribuição total de reconhecimentos para o tráfego no relê de célula então é:
<formula>formula see original document page 337</formula>
Para se tornar o problema tratável, é necessário fazer hipóteses adicionais. Uma dessas hipóteses adicionais é que o número de filhos de A é grande. Neste caso, as contribuições individuais de cada Bj para o tráfego total é pequena, e a taxa de sucesso de pacote se torna independente de i, conforme se segue:
<formula>formula see original document page 337</formula>
Para simplificar a expressão para a taxa de sucesso de reconhecimento, nós notamos que uma implementação do presente assunto de protocolo não resulta em um sistema Aloha puro. Quando um filho de um ponto final de nível 2 ouve seu pai enviar um pacote, ele posterga sua própria transmissão, para evitar interferir com o reconhecimento que seu pai está esperando. A probabilidade de Bi receber no mesmo intervalo de tempo um reconhecimento de um de seus filhos (pretendido para seu neto) e um reconhecimento de A também é muito menor do que previamente assumido. Isto ocorreria apenas se, no intervalo de tempo prévio, Bi tivesse enviado um pacote para Aeo filho de Bi também tivesse enviado um pacote para seu próprio filho. É provável que isto produza uma colisão. A taxa de sucesso de reconhecimento, portanto, será aproximada por:
ASR(AtB) = PSRe
onde nós assumimos ainda que a taxa de colisão externa seja a mesma para todos os pontos finais.
A relação entre o ritmo de transferência e a densidade de tráfego de entrada no relê de célula é simplificada para:
T (Bi A, A) = PSR(B1A) ASR(AiB) R(Bi A, A)
A taxa de reconhecimento de nível 2 para nível 3 é aproximada da mesma forma:
ASR( BiySof (B1))- PSR.
E a densidade de entrada de reconhecimento no relê de célula se torna:
<formula>formula see original document page 338</formula>
onde se usa a conservação do número de pacotes de nível para nível. A PSR de B para A pode ser expressa, agora, como:
<formula>formula see original document page 338</formula>
Após uma substituição na relação entre T (B, A, A) e R (B, A, A), é obtido o seguinte: <formula>formula see original document page 339</formula>
Isto pode ser escrito desta forma:
<formula>formula see original document page 339</formula>
0 lado esquerdo desta equação é uma função monotônica de T (B, A1 A) , o lado direito tem um valor máximo para R (B, A, A) = 1, e segue-se uma equação que pode ser resolvida para se encontrar o valor máximo possível de T (Bt A, A) :
<formula>formula see original document page 339</formula>
As presentes Figuras 76 e 77, respectivamente, ilustram vários aspectos dessas relações. Em particular, a presente Figura 76 ilustra de forma gráfica o ritmo de transferência de dados, T (B, A, A) e a PSR (com reconhecimento) versus a densidade de entrada de tráfego, R (B, A, A) para PSRe = 0,8, enquanto a presente Figura 75 ilustra graficamente o ritmo de transferência de dados, T (B, A, A) versus PSRe. Em qualquer caso, qualquer que seja a taxa de colisão externa, o ritmo de transferência máximo sempre é obtido para R (B, A, A) = 1. Esse recurso interessante é usado para um gerenciamento de carga de tráfego pelo presente assunto de protocolo.
Em contraste com a discussão precedente concernente a uma análise do fluxo de tráfego de transferência (via upload) no relê de célula, de acordo com o presente assunto de protocolo, o que vem a seguir se refere mais particularmente a uma avaliação desse fluxo de tráfego de transferência (via upload).
De modo a se controlar apropriadamente a carga de tráfego pelo presente assunto, um ponto final precisa avaliar a quantidade de tráfego indo através da rede. A partir da teoria eletromagnética, é sabido que qualquer percurso de transmissão de antena para antena é reciproco. Por simplicidade, pode-se fazer uma hipótese adicional que os enlaces são equilibrados, isto é, as potências transmitidas e as sensibilidades são as mesmas para todos os pontos finais. Pode-se dizer, então, que se o nó A for um pai para o nó Bi, todo pacote transmitido por A será ouvido por Bi, com exceção dos pacotes perdidos por colisão, ou porque Bi não estava no modo de recepção no momento correto. Isto provê a um nó Bi uma forma simples aproximada de conhecer a quantidade de tráfego com que seu pai está lidando no momento. O nó Bi precisa ouvir os reconhecimentos transmitidos pelo relê de célula. Os reconhecimentos proporcionarão informação suficiente para a avaliação da carga de tráfego.
Para cada pacote recebido, o relê de célula envia um reconhecimento. Portanto, é calculado que U (A, B, Bi) = S (Β,A,A) . A taxa de reconhecimentos recebidos de forma bem sucedida por Bi é dada por:
V(Α,B,Β,)= U(A,B,B,) ASR (A,B,)Q(B1)
onde Q(Bi) é incluído porque o ponto final Bi está monitorando reconhecimentos pretendidos para outros pontos finais e nem sempre está no estado de escuta, quando estes reconhecimentos chegarem.
É sabido que a densidade de entrada de tráfego é dada por R (B, A, A) = S (B, A, A) / PSR (A, Β) . A relação entre R(B, A, A) e V (A, B, Bi) é:
Quando se mede V (A, B, B1), devem-se considerar todos os reconhecimentos (positivos ou negativos) enviados por A e recebidos por Bi. Mas os reconhecimentos pretendidos para Bi não são levados em consideração nesta computação. Apenas os reconhecimentos endereçados a outros pontos finais são registrados, porque a finalidade é avaliar o tráfego em questão externo com que o ponto final A tem que lidar. V (A, B, Bi) pode ser medido contando-se todos os reconhecimentos recebidos ocorrendo em uma janela de tempo móvel. Se a taxa de sucesso de pacote for expressa em termos do atraso de propagação médio, o resultado será conforme se segue:
<formula>formula see original document page 341</formula>
A densidade de tráfego de entrada pode ser vista pelo ponto final A como uma função do atraso de propagação e da taxa de recepção de reconhecimentos. A equação a seguir indicará quão ocupado é o ponto final A:
<formula>formula see original document page 341</formula> O que vem a seguir se refere mais particularmente a algoritmos de gerenciamento de tráfego pelo presente assunto de protocolo. Quando a camada de LLC recebe a partir da camada de NET uma requisição para enviar um pacote, ou quando ela reprograma uma transmissão não reconhecida, ela computará o comprimento do tempo de espera (Tx_Wait), antes de a requisição para enviar ser encaminhada para a camada de MAC. Este tempo de espera é computado como uma função do número de repetição. A finalidade dessa abordagem é evitar inundar a interface de ar com um grande número de pacotes, quando as condições de transmissão forem difíceis.
Quando a camada de MAC recebe uma requisição para enviar um pacote a partir da camada de LLC, o comprimento de janela de randomização (Tx_Window) é computado como uma função da carga de tráfego, sua finalidade sendo evitar usar a interface de Aloha com intervalo acima de seu ponto ótimo. A transmissão de um pacote sempre ocorrerá na janela de randomização, após o tempo de espera. Essa faceta do presente assunto é ilustrada pela presente Figura 80, a qual representa graficamente o tempo de espera e a janela de randomização para a (re)transmissão de um pacote. Esse tempo de espera preferencialmente é computado de acordo com uma lei de retorno após colisão exponencial binária, conforme explicado de outra forma aqui.
0 que vem a seguir se dirige mais particularmente a uma mitigação vantajosa de circunstâncias de colisão pelo presente assunto. Neste contexto, a recepção simultânea de dois ou mais pacotes é referida como uma colisão. Se os pacotes colidindo tiverem a mesma potência, ambos serão perdidos. Se um pacote for recebido com uma potência mais alta (mais alta do que alguma relação de portador para interferência) e se o pacote mais potente chegar primeiro, o pacote mais forte será recebido de forma bem sucedida e o mais fraco será perdido. Um conjunto de condições como esse e/ou eventos é representado pela presente Figura 79, isto é, que representa um episódio de colisão como esse, em que um pacote (designado como o pacote 1) é perdido.
Se um pacote mais fraco chegar primeiramente, dois cenários serão possíveis, dependendo do tipo de receptor usado na porção pertinente da implementação. Se o receptor tiver funcionalidades relativamente mais limitadas, ele travará no preâmbulo do primeiro pacote, indo para uma busca de palavra de sincronização e, então, para uma fase de demodulação. Quando o pacote mais forte chega, o receptor não está em um estado de busca de preâmbulo e perde a palavra de sincronização do pacote mais forte.
Ambos os pacotes são perdidos. Um conjunto de condições e/ou de eventos como esse é representado pela presente Figura 80, isto é, representando um episódio de colisão em que ambos os pacotes (designados como pacote 1 e pacote 2) são perdidos. Na situação em que o receptor calha de ser um dispositivo mais sofisticado, o receptor é capaz de demodular um pacote e concorrentemente buscar um novo preâmbulo. Nesse caso, ele pode receber o pacote mais forte.O mais fraco (pacote 1), contudo, é perdido em todos os casos.
Para mitigação da probabilidade de colisão com qualquer tipo de receptor, pode ser útil pelo presente assunto evitar usar o primeiro subintervalo de tempo para reconhecimentos. Essa abordagem preferida evitará a destruição de alguns pacotes por reconhecimentos mais fracos chegando imediatamente antes do pacote.
Embora o presente assunto tenha sido descrito em detalhes com respeito a modalidades específicas do mesmo, será apreciado que aqueles versados na técnica, mediante a obtenção de um entendimento do precedente, podem prontamente produzir alterações em, variações de e equivalentes a essas modalidades. Assim sendo, o escopo da presente exposição é a título de exemplo, ao invés de a título de limitação, e o assunto não impede a inclusão dessas modificações, variações e/ou adições ao presente assunto, conforme seria prontamente evidente para alguém de conhecimento comum na técnica.
Além disso, a discussão variada aqui nos traz e/ou se baseia em abreviações e acrônimos, tendo os significados pretendidos conforme estabelecido na Lista de Definições a seguir, a qual faz parte da presente exposição.
Lista de Definições
• b ACK - Reconhecimento
• AMI - Iniciativa de medição avançada
• API - Interface de camada de aplicativo
• C12.22 - protocolo de norma ANSI para a criação de uma interface para redes de comunicação de dados. É o protocolo de API recomendado para ser usado com o protocolo Linknet.
• CM - Mestre de célula.
• CR - Relê de célula.
• CRC - Verificação de redundância cíclica.
• ERC - Comitê Europeu de Radiocomunicações. • EP - Ponto final, nó de rede.
• EP_GPD - Atraso de propagação médio global entre um ponto final e o mestre de célula através de um vizinho especificado.
• ETSI - Instituto Europeu de Normas de Telecomunicações
• FCC - Comissão Federal de Comunicações
• FCS - Seqüência de verificação de quadro
• FEC - Correção de erro antecipada
• FH- Salto de freqüência
• FHSS - Espectro de dispersão de salto de freqüência
• GF- Campo de Galois
• GPD - Atraso de propagação médio global entre um ponto final e um mestre de célula (o EP_GPD mínimo para um ponto final).
• IEEE - Institute of Electrical and Electronics Engineers
• ISM - Industrial, científico e médico
• ISO - International Standards Organization
• ITP - Protocolo de tempo Itron
• Linknet - O nome do protocolo descrito no presente documento.
• LLC - Camada de controle de enlace lógico.
• LPDU - PDU de LLC.
• LPD - PD local. Atraso de propagação entre dois EPs vizinhos.
• MAC - camada de acesso de controle a meio.
• MPDU - PDU de MAC.
• NACK - Reconhecimento negativo.
• NET - Camada de rede.
• NETPDU - PDU de NET. • OSI - Interconexão de sistemas abertos.
• PDF - Função de densidade de probabilidade.
• PDU - Unidade de dados de protocolo.
• PHY - Camada física.
• PPDU -PDU de camada física.
• PSR - Taxa de sucesso de pacote.
• RITP - Protocolo de tempo Itron relativo.
• RS - Reed-Solomon ou estado registrado.
• RSSI - Indicador de intensidade de sinal recebido.
• RTOS - Sistema operacional em tempo real.
• SAP - Ponto de acesso de serviço.
• SFD - Começo de delimitador de quadro.
• TS - Intervalo de tempo.
• RF2Net - Nome de projeto prévio para o desenvolvimento de Linknet.
• WAN - Rede de área local
• Zigbee - Protocolo de padrão do IEEE.
Claims (22)
1. Metodologia para uma rede de malha de sistema de medição avançado com gerenciamento de vizinhança adaptativo de enlaces de comunicações, caracterizada pelo fato de compreender: o estabelecimento de uma rede que inclui uma instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo dispositivos de nó pais os quais provêem um enlace de comunicações para outros dos dispositivos de nó definindo dispositivos de nó filhos os quais provêem um enlace dè comunicações para outros dos dispositivos de nó definindo dispositivos de nó filhos para um dado respectivo dispositivo de nó pai; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos de nó através de associações com respectivos dispositivos dos dispositivos de nó pais; a partir de cada dispositivo de nó filho existente associado a um dado dispositivo de nó pai especifico, a provisão de uma informação de modo que esse dispositivo de nó pai especifico sobre enlaces de comunicações pais alternativos disponíveis para esse dispositivo de nó filho existente; para cada dispositivo de nó pai, mediante o recebimento de uma requisição de um dispositivo de nó não filho para se tornar um dispositivo de nó filho do mesmo, a avaliação dessa informação a partir de seus dispositivos de nó filhos existentes e a avaliação de sua capacidade para aceitação de um novo dispositivo de nó filho, e se tiver essa capacidade, a aceitação dessa requisição de um dispositivo de nó não filho como um novo dispositivo de nó filho do mesmo, ou se não tiver essa capacidade, a remoção de seus dispositivos de nó filhos existentes de um dispositivo de nó filho existente o qual indicou um enlace de comunicações pai alternativo disponível para ele e, então, a aceitação desse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo.
2. Metodologia, de acordo com a reivindicação 1, caracterizada pelo fato de um dispositivo de nó filho existente ser sincronizado com seu respectivo dispositivo de nó pai.
3. Metodologia, de acordo com a reivindicação 2, caracterizada pelo fato de um dispositivo de nó pai enviar uma notificação de remoção para qualquer dispositivo de nó filho existente o qual ele esteja removendo como um dispositivo de nó filho; e esse dispositivo de nó filho removido após isso readquire uma sincronização com um de seus enlaces de comunicações pais alternativos disponíveis.
4. Metodologia, de acordo com a reivindicação 1, caracterizada pelo fato de enlaces de comunicações pais alternativos disponíveis compreenderem pais e irmãos disponíveis para um respectivo dispositivo de nó para sincronização com ele, e a informação passada de um dispositivo filho existente para seu respectivo dispositivo pai existente com o qual ele é sincronizado é se o número desses pais e irmãos está ou não disponível para um respectivo dispositivo de nó para sincronização com ele está acima de um limite predeterminado.
5. Metodologia para uma rede de malha de sistema de medição avançado com gerenciamento adaptativo de enlaces de comunicações de pai e filho, caracterizada pelo fato de compreender: o estabelecimento de uma rede incluindo uma instalação central e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, pelo menos alguns desses dispositivos de nó compreendendo mestres de célula os quais provêem comunicações entre a instalação central e outros dos dispositivos de nó associados a ele 'em respectivas células formadas por cada respectivo mestre de célula, e pelo menos alguns desses dispositivos de nó compreendem dispositivos de nó pais os quais provêem um enlace de comunicações sincronizado entre um respectivo mestre de célula e outros dos dispositivos de nó definindo dispositivos de nó filhos de um dado respectivo dispositivo de nó pai; a configuração da rede para comunicações bidirecionais entre a instalação central e cada um da pluralidade de dispositivos de nó através de associações com respectivos dispositivos de nó pais e dos mestres de célula; em cada dispositivo de nó, o estabelecimento e a atualização de uma informação sobre cada um desses dispositivos de nó e suas respectivas relações de vizinho e enlaces de comunicações, incluindo uma notificação de indicador tipo de flag confirmando que esse dispositivo de nó está disponível para seus pais potenciais acima de um número predeterminado do mesmo, cada um desses dispositivos de nó incluindo essa notificação de indicador tipo de flag como aplicável em suas transmissões; em cada dispositivo de nó pai, a monitoração dessas notificações de indicador tipo de flag a partir de seus dispositivos de nó filhos existentes e, mediante o recebimento de uma requisição de sincronização a partir de um dispositivo de nó não filho quanto a se tornar um dispositivo de nó filho do mesmo, a avaliação dessas notificações de indicador tipo de flag a partir de seus dispositivos de nó filhos existentes e a avaliação desta capacidade para aceitar um novo dispositivo de nó filho, e se tiver essa capacidade, a sincronização com esse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo, ou se não tiver essa capacidade, a remoção de seus dispositivos de nó filhos existentes de um dispositivo de nó filho existente o qual através de sua notificação de indicador tipo de flag indicou um enlace de comunicação pai alternativo disponível para ele, o envio de uma notificação de remoção para esse dispositivo de nó filho existente sendo removido, e a sincronização com esse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo, por meio do que dispositivos de nó não filhos não são recusados para sincronização na rede.
6. Metodologia, de acordo com a reivindicação 5, caracterizada pelo fato de: essa informação sobre cada um desses dispositivos de nó e suas respectivas relações de vizinho e enlaces de comunicações incluírem uma confirmação que esse dispositivo de nó tem disponíveis para ele pais e irmãos em potencial para uma sincronização disponível com ele, e acima de um número predeterminado disso; e qualquer dispositivo de nó filho removido por seu respectivo dispositivo de nó pai prévio após isso readquirir uma sincronização com um de seus enlaces de comunicações de sincronização alternativos disponíveis.
7. Metodologia, de acordo com a reivindicação 5, caracterizada pelo fato de cada respectivo dispositivo de nó pai manter uma tabela de dispositivos de nó filhos existentes, e a avaliação da capacidade de um dispositivo de nó pai em particular para aceitar um novo dispositivo de nó filho ser com base em se essa tabela mantida desse respectivo dispositivo de nó pai estar cheia.
8. Metodologia, de acordo com a reivindicação 5, caracterizada pelo fato de a notificação de indicador tipo de flag compreender um bit regulado em um formato de mensagem de transmissões a partir de cada respectivo dispositivo de nó.
9. Metodologia, de acordo com a reivindicação 5, caracterizada pelo fato de: a referida informação sobre cada um desses dispositivos de nó e suas respectivas relações de vizinho e enlaces de comunicações incluir uma confirmação que esse dispositivo de nó tem disponíveis para ele pais e irmãos em potencial para uma sincronização disponível com eles, e acima de um número predeterminado do mesmo; a notificação de indicador tipo de flag compreender um bit regulado em um formato de mensagem de transmissões a partir de cada respectivo dispositivo de nó; qualquer dispositivo de nó filho removido por seu respectivo dispositivo de nó pai prévio após isso readquirir uma sincronização com um de seus enlaces de comunicações de sincronização alternativos disponíveis; e cada respectivo dispositivo de nó pai manter uma tabela de dispositivos de nó filhos existentes, e a avaliação da capacidade de um dispositivo de nó pai em particular de aceitar um novo dispositivo de nó filho é com base em se essa tabela mantida desse respectivo dispositivo de nó pai está cheia.
10. Rede de malha de sistema de medição avançado com gerenciamento de vizinhança adaptativo de enlaces de comunicações, caracterizada pelo fato de compreender: uma instalação central; e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo dispositivos de nó pais os quais provêem um enlace de comunicações para outros dos referidos dispositivos de nó definindo dispositivos de nó filhos de um dado respectivo dispositivo de nó pai, com a referida rede configurada para comunicações bidirecionais entre a referida instalação central e cada um da referida pluralidade de dispositivos de nó através de associações com respectivos dos referidos dispositivos de nó pais; onde cada dispositivo de nó filho existente associado a um dado dispositivo de nó pai específico é adicionalmente configurado para a provisão de uma informação para esse dado dispositivo de nó pai específico sobre enlaces de comunicações pais alternativos disponíveis para esse dispositivo de nó filho existente; cada dispositivo de nó pai é adicionalmente configurado para receber uma requisição a partir de um dispositivo de nó não filho para se tornar um dispositivo de nó filho do mesmo, para avaliação dessa informação a partir de seus dispositivos de nó filhos existentes e avaliação de sua capacidade de aceitar um novo dispositivo de nó filho, e se tiver essa capacidade, a aceitação dessa requisição de um dispositivo de nó não filho como um novo dispositivo de nó filho do mesmo, ou se não tiver essa capacidade, a remoção de seus dispositivos de nó filhos existentes de um dispositivo de nó filho existente o qual indicou um enlace de comunicações pai alternativo disponível para ele e, então, a aceitação desse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo.
11. Rede de malha de sistema de medição avançado, de acordo com a reivindicação 10, caracterizada pelo fato de um dispositivo de nó filho existente ser sincronizado com seu respectivo dispositivo de nó pai.
12. Rede de malha de sistema de medição avançado, de acordo com a reivindicação 11, caracterizada pelo fato de cada respectivo dispositivo de nó pai ser adicionalmente configurado para enviar uma notificação de remoção para qualquer dispositivo de nó filho existente o qual ele esteja removendo como um dispositivo de nó filho; e esse dispositivo de nó filho removido ser adicionalmente configurado para após isso readquirir uma sincronização com um de seus enlaces de comunicações pais alternativos disponíveis.
13. Rede de malha de sistema de medição avançado, de acordo com a reivindicação 10, caracterizada pelo fato de enlaces de comunicações pais alternativos disponíveis compreenderem pais e irmãos disponíveis para um respectivo dispositivo de nó para sincronização com ele, e a informação passada de um dispositivo filho existente para seu respectivo dispositivo pai existente com o qual ele é sincronizado é se o número desses pais e irmãos está ou não disponível para um respectivo dispositivo de nó para sincronização com ele está acima de um limite predeterminado.
14. Rede de malha de sistema de medição avançado com gerenciamento adaptativo de enlaces de comunicações de pai e filho, caracterizada pelo fato de compreender: uma instalação central; e uma pluralidade de dispositivos de nó, pelo menos alguns desses dispositivos de nó compreendendo dispositivos de metrologia, pelo menos alguns desses dispositivos de nó compreendendo mestres de célula os quais provêem comunicações entre a instalação central e outros dos dispositivos de nó associados a ele em respectivas células formadas por cada respectivo mestre de célula, e pelo menos alguns desses dispositivos de nó compreendem dispositivos de nó pais os quais provêem um enlace de comunicações sincronizado entre um respectivo mestre de célula e outros dos dispositivos de nó definindo dispositivos de nó filhos de um dado respectivo dispositivo de nó pai, com a referida rede configurada para comunicações bidirecionais entre a referida instalação central e cada um da referida pluralidade de dispositivos de nó através de associações com respectivos referidos dispositivos de nó pais e dos referidos mestres de célula; onde cada dispositivo de nó é configurado para o estabelecimento e a atualização de uma informação sobre suas respectivas relações de vizinho e enlaces de comunicações, incluindo uma notificação de indicador tipo de flag confirmando que esse dispositivo de nó está disponível para seus pais potenciais acima de um número predeterminado do mesmo, e ainda é configurado para incluir essa notificação de indicador tipo de flag como aplicável em suas transmissões; cada dispositivo de nó pai é adicionalmente configurado para a monitoração dessas notificações de indicador tipo de flag a partir de seus dispositivos de nó filhos existentes e, mediante o recebimento de uma requisição de sincronização a partir de um dispositivo de nó não filho quanto a se tornar um dispositivo de nó filho do mesmo, a avaliação dessas notificações de indicador tipo de flag a partir de seus dispositivos de nó filhos existentes e a avaliação desta capacidade para aceitar um novo dispositivo de nó filho, e se tiver essa capacidade, a sincronização com esse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo, ou se não tiver essa capacidade, a remoção de seus dispositivos de nó filhos existentes de um dispositivo de nó filho existente o qual através de sua notificação de indicador tipo de flag indicou um enlace de comunicação pai alternativo disponível para ele, o envio de uma notificação de remoção para esse dispositivo de nó filho existente sendo removido, e a sincronização com esse dispositivo de nó não filho requisitante como um novo dispositivo de nó filho do mesmo, por meio do que dispositivos de nó não filhos não são recusados para sincronização na rede.
15. Rede de malha de sistema de medição avançado, de acordo com a reivindicação 14, caracterizada pelo fato de: cada dispositivo de nó ser adicionalmente configurado para que essa informação sobre cada um desses dispositivos de nó e suas respectivas relações de vizinho e enlaces de comunicações inclua uma confirmação que esse dispositivo de nó tem disponíveis para ele pais e irmãos em potencial para uma sincronização disponível com ele, e acima de um número predeterminado disso; e qualquer dispositivo de nó filho removido por seu respectivo dispositivo de nó pai prévio ser adicionalmente configurado para após isso readquirir uma sincronização com um de seus enlaces de comunicações de sincronização alternativos disponíveis.
16. Rede de malha de sistema de medição avançado, de acordo com a reivindicação 14, caracterizada pelo fato de cada respectivo dispositivo de nó pai manter uma tabela de dispositivos de nó filhos existentes, e a avaliação da capacidade de um dispositivo de nó pai em particular para aceitar um novo dispositivo de nó filho ser com base em se essa tabela mantida desse respectivo dispositivo de nó pai estar cheia.
17. Rede de malha de sistema de medição avançado, de acordo com a reivindicação 14, caracterizada pelo fato de cada respectivo dispositivo de nó ser adicionalmente configurado para que a transmissão dessa notificação de indicador tipo de flag compreenda um bit regulado em um formato de mensagem de transmissões a partir de cada respectivo dispositivo de nó.
18. Rede de malha de sistema de medição avançado, de acordo com a reivindicação 14, caracterizada pelo fato de: cada dispositivo de nó ser adicionalmente configurado para que essa informação sobre cada um desses dispositivos de nó e suas respectivas relações de vizinho e enlaces de comunicações inclua uma confirmação que esse dispositivo de nó tem disponíveis para ele pais e irmãos em potencial para uma sincronização disponível com eles, e acima de um número predeterminado do mesmo; cada respectivo dispositivo de nó ser adicionalmente configurado para que uma transmissão dessa notificação de indicador tipo de flag compreenda a inclusão de um bit regulado em um formato de mensagem de transmissões a partir de cada respectivo dispositivo de nó; qualquer dispositivo de nó filho removido por seu respectivo dispositivo de nó pai prévio ser adicionalmente configurado para após isso readquirir uma sincronização com um de seus enlaces de comunicações de sincronização alternativos disponíveis; e cada respectivo dispositivo de nó pai manter uma tabela de dispositivos de nó filhos existentes, e a avaliação da capacidade de um dispositivo de nó pai em particular de aceitar um novo dispositivo de nó filho é com base em se essa tabela mantida desse respectivo dispositivo de nó pai está cheia.
19. Dispositivo de metrologia para uso com uma rede de malha de sistema de medição avançado com gerenciamento de vizinhança adaptativo de enlaces de comunicações, e incluindo uma instalação central, uma pluralidade de dispositivos de nó, com pelo menos alguns desses dispositivos de nó compreendendo esses dispositivos de metrologia, e pelo menos alguns desses dispositivos de nó compreendendo dispositivos de nó pais provendo enlaces de comunicações sincronizados para outros dos dispositivos de nó definindo dispositivos de nó filhos de um dado respectivo dispositivo de nó pai, com cada dispositivo de nó configurado para comunicações bidirecionais com essa instalação central através de associações com respectivos dos dispositivos de nó pais, o referido dispositivo de metrologia caracterizado pelo fato de compreender: uma porção de metrologia configurada para medir o consumo de um bem de consumo de serviço de utilidade pública; uma porção de transmissor configurada para transmitir uma informação de consumo e outros dados; e uma porção de receptor configurada para receber uma informação a partir de outros dispositivos de rede em uma rede associada; onde as referidas porções de dispositivo de metrologia são configuradas para proverem para seu respectivo dispositivo de nó pai uma informação de rede associada sobre enlaces de comunicações pais alternativos disponíveis para esse dispositivo de metrologia nessa rede associada, de modo que esse respectivo dispositivo de nó pai possa fazer determinações sobre a remoção desse dispositivo de metrologia como um filho do mesmo, no lugar de outros dispositivos de nó nessa rede associada.
20. Dispositivo de metrologia, de acordo com a reivindicação 19, caracterizado pelo fato de as referidas porções de dispositivo de metrologia serem adicionalmente configuradas para incluírem em transmissões a partir do referido dispositivo de metrologia uma notificação de indicador tipo de flag indicando se esse dispositivo de metrologia tem disponíveis para ele pais potenciais acima de um número predeterminado dos mesmos.
21. Dispositivo de metrologia, de acordo com a reivindicação 20, caracterizado pelo fato de as referidas porções de dispositivo de metrologia serem adicionalmente configuradas para que uma transmissão dessa notificação de indicador tipo de flag inclua um bit regulado em um formato de mensagem de transmissões a partir desse dispositivo de metrologia.
22. Dispositivo de metrologia, de acordo com a reivindicação 19, caracterizado pelo fato de as referidas porções de dispositivo de metrologia serem adicionalmente configuradas para responderem a uma notificação de remoção de seu respectivo dispositivo de nó pai de uma rede associada por readquirirem, após isso, uma sincronização com um de seus enlaces de comunicações pais alternativos disponíveis.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US84505606P | 2006-09-15 | 2006-09-15 | |
| US84599406P | 2006-09-20 | 2006-09-20 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0722400A2 true BRPI0722400A2 (pt) | 2012-06-05 |
Family
ID=39184383
Family Applications (14)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0722400-1A BRPI0722400A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0722393-5A BRPI0722393A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula / nó |
| BRPI0722398-6A BRPI0722398A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0722397-8A BRPI0722397A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0716887-0A BRPI0716887A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de mediÇço e utilizaÇço e gerencimento de cÉlula/nà |
| BRPI0722402-8A BRPI0722402A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0722394-3A BRPI0722394A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0722396-0A BRPI0722396A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0722403-6A BRPI0722403A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula / nó |
| BRPI0722395-1A BRPI0722395A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula / nó |
| BRPI0722401-0A BRPI0722401A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula / nó |
| BRPI0722404-4A BRPI0722404A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula / nó |
| BRPI0722399-4A BRPI0722399A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0722392-7A BRPI0722392A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
Family Applications After (13)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0722393-5A BRPI0722393A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula / nó |
| BRPI0722398-6A BRPI0722398A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0722397-8A BRPI0722397A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0716887-0A BRPI0716887A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de mediÇço e utilizaÇço e gerencimento de cÉlula/nà |
| BRPI0722402-8A BRPI0722402A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0722394-3A BRPI0722394A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0722396-0A BRPI0722396A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0722403-6A BRPI0722403A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula / nó |
| BRPI0722395-1A BRPI0722395A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula / nó |
| BRPI0722401-0A BRPI0722401A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula / nó |
| BRPI0722404-4A BRPI0722404A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula / nó |
| BRPI0722399-4A BRPI0722399A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
| BRPI0722392-7A BRPI0722392A2 (pt) | 2006-09-15 | 2007-09-14 | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
Country Status (7)
| Country | Link |
|---|---|
| US (26) | US8059009B2 (pt) |
| EP (14) | EP2207384B1 (pt) |
| AU (15) | AU2007294728B2 (pt) |
| BR (14) | BRPI0722400A2 (pt) |
| CA (7) | CA2941376C (pt) |
| MX (1) | MX2009002801A (pt) |
| WO (1) | WO2008033514A2 (pt) |
Families Citing this family (509)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7343413B2 (en) * | 2000-03-21 | 2008-03-11 | F5 Networks, Inc. | Method and system for optimizing a network by independently scaling control segments and data flow |
| KR100703780B1 (ko) * | 2005-05-11 | 2007-04-06 | 삼성전자주식회사 | 무선 네트워크에서 라우팅 테이블의 정보를 일치시키는방법 및 장치 |
| US7676733B2 (en) * | 2006-01-04 | 2010-03-09 | Intel Corporation | Techniques to perform forward error correction for an electrical backplane |
| US20080016248A1 (en) * | 2006-07-14 | 2008-01-17 | George Tsirtsis | Method and apparatus for time synchronization of parameters |
| GB2440980A (en) * | 2006-08-18 | 2008-02-20 | Fujitsu Ltd | Wireless multi-hop communication system |
| US8312103B2 (en) * | 2006-08-31 | 2012-11-13 | Itron, Inc. | Periodic balanced communication node and server assignment |
| US20080074285A1 (en) * | 2006-08-31 | 2008-03-27 | Guthrie Kevin D | Interface between meter and application (IMA) |
| US20080071930A1 (en) * | 2006-09-01 | 2008-03-20 | Holbrook Kenneth J | Native network transport |
| US9354083B2 (en) * | 2006-09-15 | 2016-05-31 | Itron, Inc. | Home area networking (HAN) with low power considerations for battery devices |
| US8787210B2 (en) | 2006-09-15 | 2014-07-22 | Itron, Inc. | Firmware download with adaptive lost packet recovery |
| US8059009B2 (en) * | 2006-09-15 | 2011-11-15 | Itron, Inc. | Uplink routing without routing table |
| US9143332B2 (en) * | 2006-10-31 | 2015-09-22 | Siemens Industry, Inc. | Method and tool for wireless communications with sleeping devices in a wireless sensor control network |
| TWI316347B (en) * | 2006-11-06 | 2009-10-21 | Inst Information Industry | System, method, computer program product, and computer readable medium for a new node joining the wireless network |
| EP1940190B1 (en) * | 2006-12-29 | 2013-11-20 | Motorola Mobility LLC | A cellular wireless communication device and method for managing the receipt of a handover command |
| US8036330B2 (en) * | 2006-12-29 | 2011-10-11 | Samsung Electronics Co., Ltd. | System and method for frequency synchronization in a wireless non-hierarchical network |
| US8036247B2 (en) | 2007-01-05 | 2011-10-11 | Frank Paul R | System and method of synchronizing real time clock values in arbitrary distributed systems |
| US8489136B2 (en) * | 2007-01-05 | 2013-07-16 | Aliphcom | Wireless link to transmit digital audio data between devices in a manner controlled dynamically to adapt to variable wireless error rates |
| KR101421569B1 (ko) * | 2007-02-13 | 2014-07-24 | 에스케이텔레콤 주식회사 | 무선 개인 통신 네트워크에서 비컨 테이블을 이용한 비컨슬롯 결정 방법 및 무선 근거리 개인 통신 기기 |
| WO2008100496A1 (en) * | 2007-02-13 | 2008-08-21 | Gainspan Corporation | Preferential transmission of non-coded data over forward error correction coded data for efficient power management of a remote device |
| US8111684B2 (en) * | 2007-03-30 | 2012-02-07 | Cisco Technology, Inc. | Path shortening in a wireless mesh network |
| WO2008153016A1 (ja) | 2007-06-11 | 2008-12-18 | Ngk Insulators, Ltd. | 水素分離膜、及び選択透過膜型反応器 |
| US20090083416A1 (en) * | 2007-09-20 | 2009-03-26 | Siemens Building Technologies, Inc. | Methods to verify wireless node placement for reliable communication in wireless sensor control networks |
| CN101136837A (zh) | 2007-09-21 | 2008-03-05 | 华为技术有限公司 | 推送消息的控制方法、装置和系统 |
| US8320824B2 (en) | 2007-09-24 | 2012-11-27 | Aliphcom, Inc. | Methods and systems to provide automatic configuration of wireless speakers |
| CN101399757B (zh) * | 2007-09-25 | 2011-02-02 | 华为技术有限公司 | 跟踪时钟源的方法和装置 |
| CA2703546A1 (en) | 2007-10-25 | 2009-04-30 | Trilliant Networks, Inc. | Gas meter having ultra-sensitive magnetic material retrofitted onto meter dial and method for performing meter retrofit |
| US8184632B1 (en) | 2007-11-01 | 2012-05-22 | Cisco Technology, Inc. | System and method for accepting information from routing messages into a list |
| US8670325B1 (en) | 2007-11-01 | 2014-03-11 | Cisco Technology, Inc. | System and method for providing route information |
| WO2009067256A2 (en) | 2007-11-25 | 2009-05-28 | Trilliant Networks, Inc. | System and method for power outage and restoration notification in an advanced metering infrastructure network |
| US20090138713A1 (en) * | 2007-11-25 | 2009-05-28 | Michel Veillette | Proxy use within a mesh network |
| WO2009067261A1 (en) * | 2007-11-25 | 2009-05-28 | Trilliant Networks, Inc. | System and method for transmitting and receiving information on a neighborhood area network |
| US8138934B2 (en) | 2007-11-25 | 2012-03-20 | Trilliant Networks, Inc. | System and method for false alert filtering of event messages within a network |
| US20090136042A1 (en) * | 2007-11-25 | 2009-05-28 | Michel Veillette | Application layer authorization token and method |
| US20090135843A1 (en) * | 2007-11-25 | 2009-05-28 | Michel Veillette | System and method for operating mesh devices in multi-tree overlapping mesh networks |
| EP2215550A1 (en) | 2007-11-25 | 2010-08-11 | Trilliant Networks, Inc. | Energy use control system and method |
| PT2065863E (pt) * | 2007-11-30 | 2011-02-10 | Siemens Ag | Determinação da qualidade de uma ligação de comunicação num sistema de sinalização de emergência de multisaltos via rádio |
| KR100932923B1 (ko) * | 2007-12-17 | 2009-12-21 | 한국전자통신연구원 | 무선센서네트워크에서 라우팅 경로 설정 방법 및 장치 |
| US8442092B2 (en) * | 2007-12-27 | 2013-05-14 | Silver Spring Networks, Inc. | Creation and use of unique hopping sequences in a frequency-hopping spread spectrum (FHSS) wireless communications network |
| US8254909B1 (en) | 2008-01-03 | 2012-08-28 | At&T Intellectual Property I, L.P. | Computational syndrome detector |
| US7929446B2 (en) * | 2008-01-04 | 2011-04-19 | Radiient Technologies, Inc. | Mesh networking for wireless communications |
| US7961554B2 (en) * | 2008-01-11 | 2011-06-14 | Cellnet Innovations, Inc. | Methods and systems for accurate time-keeping on metering and other network communication devices |
| JP4586854B2 (ja) | 2008-02-05 | 2010-11-24 | ソニー株式会社 | 表示生成装置、表示生成方法、プログラム、および無線通信システム |
| US8098620B2 (en) * | 2008-03-12 | 2012-01-17 | Motorola Mobility, Inc. | Method for status reporting in wireless communication systems when one-time allocated resource is insufficent |
| US7583209B1 (en) * | 2008-03-19 | 2009-09-01 | Mitsubishi Electric Research Laboratories, Inc. | System and method for signaling on a bus using forbidden pattern free codes |
| US9203928B2 (en) | 2008-03-20 | 2015-12-01 | Callahan Cellular L.L.C. | Data storage and retrieval |
| US7599997B1 (en) | 2008-08-01 | 2009-10-06 | Gene Fein | Multi-homed data forwarding storage |
| US8458285B2 (en) * | 2008-03-20 | 2013-06-04 | Post Dahl Co. Limited Liability Company | Redundant data forwarding storage |
| US7636761B1 (en) * | 2008-09-29 | 2009-12-22 | Gene Fein | Measurement in data forwarding storage |
| US7636759B1 (en) * | 2008-09-29 | 2009-12-22 | Gene Fein | Rotating encryption in data forwarding storage |
| US8311063B2 (en) | 2008-03-28 | 2012-11-13 | Silver Spring Networks, Inc. | Updating routing and outage information in a communications network |
| US8884774B2 (en) * | 2008-04-01 | 2014-11-11 | M&Fc Holding, Llc | Universal software defined home gateway |
| US20090267792A1 (en) * | 2008-04-25 | 2009-10-29 | Henry Crichlow | Customer supported automatic meter reading method |
| US8386585B2 (en) * | 2008-04-25 | 2013-02-26 | Tajitshu Transfer Limited Liability Company | Real-time communications over data forwarding framework |
| US8396012B2 (en) * | 2008-05-01 | 2013-03-12 | Saudi Arabian Oil Company | Adaptive wireless process control system and method |
| US8452844B2 (en) * | 2008-05-07 | 2013-05-28 | Tajitshu Transfer Limited Liability Company | Deletion in data file forwarding framework |
| US8316136B2 (en) * | 2009-05-22 | 2012-11-20 | Silver Spring Networks, Inc. | Multi-protocol network registration and address resolution |
| US7783764B2 (en) * | 2008-05-27 | 2010-08-24 | Silver Spring Networks, Inc. | Multi-protocol network registration and address resolution |
| FR2932044B1 (fr) * | 2008-06-02 | 2010-08-20 | Sagem Comm | Procede et dispositif d'attribution d'adresses mac dans un reseau de communication sur courants porteurs |
| US8958441B2 (en) | 2008-06-05 | 2015-02-17 | Qualcomm Incorporated | System and method of an in-band modem for data communications over digital wireless communication networks |
| US9083521B2 (en) * | 2008-06-05 | 2015-07-14 | Qualcomm Incorporated | System and method of an in-band modem for data communications over digital wireless communication networks |
| US8825480B2 (en) * | 2008-06-05 | 2014-09-02 | Qualcomm Incorporated | Apparatus and method of obtaining non-speech data embedded in vocoder packet |
| US8725502B2 (en) * | 2008-06-05 | 2014-05-13 | Qualcomm Incorporated | System and method of an in-band modem for data communications over digital wireless communication networks |
| US8964788B2 (en) | 2008-06-05 | 2015-02-24 | Qualcomm Incorporated | System and method of an in-band modem for data communications over digital wireless communication networks |
| US8503517B2 (en) * | 2008-06-05 | 2013-08-06 | Qualcomm Incorporated | System and method of an in-band modem for data communications over digital wireless communication networks |
| JP5344543B2 (ja) * | 2008-06-11 | 2013-11-20 | 任天堂株式会社 | データ処理プログラムおよびデータ処理装置 |
| WO2009150506A1 (en) * | 2008-06-11 | 2009-12-17 | Marvell World Trade Ltd. | Dense mesh network communications |
| US20090320092A1 (en) * | 2008-06-24 | 2009-12-24 | Microsoft Corporation | User interface for managing access to a health-record |
| US9237523B2 (en) * | 2008-07-07 | 2016-01-12 | Mediatek Inc. | Method of establishing sleep mode operation for broadband wireless communications systems |
| US8599678B2 (en) | 2008-07-10 | 2013-12-03 | Tajitshu Transfer Limited Liability Company | Media delivery in data forwarding storage network |
| US8370446B2 (en) | 2008-07-10 | 2013-02-05 | Tajitshu Transfer Limited Liability Company | Advertisement forwarding storage and retrieval network |
| US8041720B2 (en) * | 2008-07-23 | 2011-10-18 | Honeywell International Inc. | Ordering telemetry messages |
| US8744336B2 (en) * | 2008-08-27 | 2014-06-03 | Qualcomm Incorporated | Interference detection apparatus and method |
| CA2734953A1 (en) * | 2008-09-04 | 2010-03-11 | Trilliant Networks, Inc. | A system and method for implementing mesh network communications using a mesh network protocol |
| KR101271918B1 (ko) | 2008-09-22 | 2013-06-05 | 한국전자통신연구원 | 무선 시스템에서 디바이스 디스커버리 운용 방법 및 그 장치 |
| US8325060B2 (en) * | 2008-09-22 | 2012-12-04 | Silver Spring Networks, Inc. | Transparent routing in a power line carrier network |
| US8352635B2 (en) * | 2008-09-29 | 2013-01-08 | Tajitshu Transfer Limited Liability Company | Geolocation assisted data forwarding storage |
| US7636762B1 (en) | 2008-09-29 | 2009-12-22 | Gene Fein | Disassembly/reassembly in data forwarding storage |
| US8478823B2 (en) | 2008-09-29 | 2013-07-02 | Tajitshu Transfer Limited Liability Company | Selective data forwarding storage |
| US8266288B2 (en) * | 2008-10-23 | 2012-09-11 | International Business Machines Corporation | Dynamic expiration of domain name service entries |
| ES2730077T3 (es) | 2008-10-27 | 2019-11-08 | Mueller Int Llc | Sistema y método de monitoreo de infraestructura |
| US8289182B2 (en) | 2008-11-21 | 2012-10-16 | Trilliant Networks, Inc. | Methods and systems for virtual energy management display |
| JP5412096B2 (ja) * | 2008-12-03 | 2014-02-12 | 株式会社やまびこ | 携帯式チェンソーの動力ユニット構造 |
| KR101179299B1 (ko) * | 2008-12-03 | 2012-09-03 | 한국전자통신연구원 | 시분할 접속을 이용한 메쉬 센서 네트워크에서 모니터링 응용을 위한 저전력 센서 노드 및 이의 라우팅 방법 |
| US8203462B2 (en) * | 2008-12-29 | 2012-06-19 | Schneider Electric USA, Inc. | Automatic registration of meters to a centralized data system |
| US8218522B2 (en) * | 2009-01-21 | 2012-07-10 | Raytheon Company | Communication scheduling of network nodes using a cluster coefficient |
| US8904177B2 (en) * | 2009-01-27 | 2014-12-02 | Sony Corporation | Authentication for a multi-tier wireless home mesh network |
| US7961674B2 (en) * | 2009-01-27 | 2011-06-14 | Sony Corporation | Multi-tier wireless home mesh network with a secure network discovery protocol |
| US8248267B2 (en) * | 2009-01-29 | 2012-08-21 | Itron, Inc. | Systems and methods for improving reception of data in wireless communication environments |
| US8248268B2 (en) * | 2009-01-29 | 2012-08-21 | Itron, Inc. | Requested time adjustment for accurate data exchange |
| US8943305B2 (en) | 2009-01-30 | 2015-01-27 | Texas Instruments Incorporated | Frame structure for medium access in body area networks (BAN) |
| US20100194592A1 (en) * | 2009-02-04 | 2010-08-05 | Raymond Yim | Method and System for Disseminating Vehicle and Road Related Information in Multi-Hop Broadcast Networks |
| US8964634B2 (en) * | 2009-02-06 | 2015-02-24 | Sony Corporation | Wireless home mesh network bridging adaptor |
| KR101633614B1 (ko) * | 2009-02-13 | 2016-06-27 | 코닌클리케 필립스 엔.브이. | 배터리 없는 지그비 디바이스를 포함하는 네트워크 내의 통신을 위한 방법과, 그에 대한 네트워크 및 디바이스 |
| CA2753283C (en) * | 2009-02-20 | 2015-04-14 | Aclara Power-Line Systems, Inc. | Wireless broadband communications network for a utility |
| EP2406778A4 (en) | 2009-03-11 | 2014-06-25 | Trilliant Networks Inc | METHOD, DEVICE AND SYSTEM FOR MAPPING TRANSFORMERS TO COUNTERS AND LOCATING NON-TECHNICAL LINE LOSSES |
| US7990897B2 (en) | 2009-03-11 | 2011-08-02 | Sony Corporation | Method and apparatus for a wireless home mesh network with network topology visualizer |
| US8203928B2 (en) * | 2009-03-31 | 2012-06-19 | Motorola Solutions, Inc. | System and method for selecting a number of spatial streams to be used for transmission based on probing of channels |
| US8838017B2 (en) * | 2009-03-31 | 2014-09-16 | Qualcomm Incorporated | Wideband jammer detector |
| WO2010121435A1 (en) * | 2009-04-24 | 2010-10-28 | Huawei Technologies Co., Ltd. | Method for generating reference signals |
| EP2427949B1 (en) | 2009-05-07 | 2020-04-08 | Virginia Electric and Power Company | Voltage conservation using advanced metering infrastructure and substation centralized voltage control |
| US8301931B2 (en) * | 2009-05-22 | 2012-10-30 | Itron, Inc. | Time synchronization of portable devices |
| US8823509B2 (en) | 2009-05-22 | 2014-09-02 | Mueller International, Llc | Infrastructure monitoring devices, systems, and methods |
| US9473963B2 (en) | 2009-05-27 | 2016-10-18 | Echo Ridge Llc | Interactive RF system testing system and method |
| US8521092B2 (en) * | 2009-05-27 | 2013-08-27 | Echo Ridge Llc | Wireless transceiver test bed system and method |
| US8488568B2 (en) * | 2009-06-02 | 2013-07-16 | Sparkmotion Inc. | Method and system of interferer signal detection |
| US8743864B2 (en) * | 2009-06-16 | 2014-06-03 | Qualcomm Incorporated | System and method for supporting higher-layer protocol messaging in an in-band modem |
| US8855100B2 (en) | 2009-06-16 | 2014-10-07 | Qualcomm Incorporated | System and method for supporting higher-layer protocol messaging in an in-band modem |
| US8892722B1 (en) * | 2009-06-22 | 2014-11-18 | Marvell International Ltd. | Peer-to-peer discovery systems and methods |
| US20120057620A1 (en) * | 2009-07-15 | 2012-03-08 | Panasonic Corporation | Radio communication device, radio communication system, radio communication method, and program for executing radio communication method |
| US8831023B2 (en) * | 2009-07-29 | 2014-09-09 | Cisco Technology, Inc. | Low latency mesh network |
| US7979578B2 (en) * | 2009-09-02 | 2011-07-12 | International Business Machines Corporation | Dynamic and evolutionary placement in an event-driven component-oriented network data processing system |
| CN102014530A (zh) * | 2009-09-04 | 2011-04-13 | 中兴通讯股份有限公司 | 一种配置更新失败后的处理方法和网元设备 |
| KR101590378B1 (ko) * | 2009-09-07 | 2016-02-02 | 에스케이텔레콤 주식회사 | 근거리 영역 내의 방송통신 융합 구간에 대한 신호 간섭 최소화 시스템 및 방법, 그리고 이에 적용되는 장치 |
| US8781462B2 (en) * | 2009-09-28 | 2014-07-15 | Itron, Inc. | Methodology and apparatus for validating network coverage |
| US20110093540A1 (en) * | 2009-09-30 | 2011-04-21 | Bae Systems Information And Electronic Systems Integration Inc. | Method and system for communications using cooperative helper nodes |
| US8548025B2 (en) * | 2009-09-30 | 2013-10-01 | Landis+Gyr Innovations, Inc. | Methods and systems for distributing broadcast messages on various networks |
| MX2012004186A (es) | 2009-10-09 | 2012-07-17 | Consert Inc | Aparatos y metodos para controlar comunicaciones a y de puntos de servicio de una compañía de electricidad. |
| US20110090820A1 (en) | 2009-10-16 | 2011-04-21 | Osama Hussein | Self-optimizing wireless network |
| JP2011101534A (ja) * | 2009-11-06 | 2011-05-19 | Panasonic Electric Works Co Ltd | 電力融通システム |
| US8867494B2 (en) * | 2009-11-09 | 2014-10-21 | Qualcomm Incorporated | System and method for single frequency dual cell high speed downlink packet access |
| CN102668465B (zh) * | 2009-11-18 | 2015-04-22 | 日本电气株式会社 | 中继装置、中继方法 |
| KR101292076B1 (ko) * | 2009-12-21 | 2013-07-31 | 한국전자통신연구원 | 보안등 근거리 무선 통신 라우팅 방법 |
| US20150302279A1 (en) * | 2009-12-22 | 2015-10-22 | Ricoh Company, Ltd. | Run Length Compression Mechanism |
| GB2469361B (en) | 2010-01-28 | 2011-04-13 | Energy2Trade Ltd | Power flow measurement and management |
| AU2011210731A1 (en) * | 2010-01-29 | 2012-07-19 | Elster Solutions, Llc | High priority data reads for acquisition of real-time data in wireless mesh network |
| US8855102B2 (en) * | 2010-01-29 | 2014-10-07 | Elster Solutions, Llc | Wireless communications providing interoperability between devices capable of communicating at different data rates |
| US8798179B2 (en) * | 2010-02-02 | 2014-08-05 | Kyocera Corporation | Radio communication device |
| US8149119B2 (en) * | 2010-02-09 | 2012-04-03 | Ekstrom Industries, Inc. | Utility meter tamper monitoring system and method |
| US20110194630A1 (en) * | 2010-02-10 | 2011-08-11 | Yang Hua-Lung | Systems and methods for reporting radio link failure |
| US9041528B2 (en) * | 2010-02-26 | 2015-05-26 | Thl Holding Company, Llc | Bridge device for use in a system for monitoring protective headgear |
| US8705418B1 (en) | 2010-03-03 | 2014-04-22 | Kbc Research Foundation Pvt. Ltd. | Methods and systems for detecting a preamble of a data packet in wireless communication systems |
| US9392565B2 (en) * | 2010-03-05 | 2016-07-12 | Samsung Electronics Co., Ltd. | Method and system for accurate clock synchronization through interaction between communication layers and sub-layers for communication systems |
| US8341457B2 (en) * | 2010-03-11 | 2012-12-25 | Lsi Corporation | System and method for optimizing redundancy restoration in distributed data layout environments |
| US20110255548A1 (en) * | 2010-04-16 | 2011-10-20 | Itron, Inc. | Gateway-based ami network |
| US8724548B2 (en) * | 2010-04-22 | 2014-05-13 | Qualcomm Incorporated | Counter check procedure for packet data transmission |
| US20110317692A1 (en) | 2010-06-03 | 2011-12-29 | Essence Security International Ltd. | Acknowledgement of communications using shared messages |
| US20110298635A1 (en) * | 2010-06-04 | 2011-12-08 | Bernie Yip | Self dynamo smart flow utility meter and system for flow utility real-time flow usage monitoring and control, self error and leakages monitoring |
| DE102010024887B4 (de) | 2010-06-11 | 2012-07-26 | Hydrometer Electronic Gmbh | Verfahren zur Standortbeurteilung für den Betrieb eines Datenfunk-Empfängers, insbesondere zur Verbrauchsdaten-Erfassung |
| CA3177996A1 (en) | 2010-06-16 | 2011-12-22 | Mueller International, Llc | Infrastructure monitoring devices, systems, and methods |
| JP5331763B2 (ja) * | 2010-08-20 | 2013-10-30 | パナソニック株式会社 | ネットワーク管理装置、基地局装置及びネットワーク管理方法 |
| WO2012027634A1 (en) | 2010-08-27 | 2012-03-01 | Trilliant Networkd, Inc. | System and method for interference free operation of co-located tranceivers |
| US20120056755A1 (en) * | 2010-09-03 | 2012-03-08 | Brooks Utility Products Group, Inc. | Utility meter tamper monitoring system and method |
| CN102401848B (zh) * | 2010-09-08 | 2014-05-07 | 国基电子（上海）有限公司 | 电表及其通信中继方法 |
| CA2813534A1 (en) | 2010-09-13 | 2012-03-22 | Trilliant Networks, Inc. | Process for detecting energy theft |
| TWI483564B (zh) * | 2010-09-16 | 2015-05-01 | Hon Hai Prec Ind Co Ltd | 電錶及其通訊中繼方法 |
| US10212687B2 (en) | 2010-09-30 | 2019-02-19 | Echo Ridge Llc | System and method for robust navigation and geolocation using measurements of opportunity |
| US9588218B2 (en) | 2010-09-30 | 2017-03-07 | Echo Ridge Llc | System and method for robust navigation and geolocation using measurements of opportunity |
| DE102010047946A1 (de) * | 2010-10-08 | 2012-04-12 | Metrona Wärmemesser Union Gmbh | Verfahren zur Konfiguration eines Netzwerks von Netzknoten sowie Verfahren und Vorrichtungsanordnung zur Übermittlung von Verbrauchsdaten dezentral angeordneter Datenerfassungsgeräte |
| US10694402B2 (en) | 2010-11-05 | 2020-06-23 | Mark Cummings | Security orchestration and network immune system deployment framework |
| US9311108B2 (en) * | 2010-11-05 | 2016-04-12 | Mark Cummings | Orchestrating wireless network operations |
| US10531516B2 (en) | 2010-11-05 | 2020-01-07 | Mark Cummings | Self organizing system to implement emerging topologies |
| US10285094B2 (en) | 2010-11-05 | 2019-05-07 | Mark Cummings | Mobile base station network |
| US10687250B2 (en) | 2010-11-05 | 2020-06-16 | Mark Cummings | Mobile base station network |
| US8774050B2 (en) * | 2010-11-09 | 2014-07-08 | Cisco Technology, Inc. | Dynamic wake-up time adjustment based on designated paths through a computer network |
| WO2012068045A2 (en) | 2010-11-15 | 2012-05-24 | Trilliant Holdings Inc. | System and method for securely communicating across multiple networks using a single radio |
| CN103222241B (zh) * | 2010-11-25 | 2017-10-03 | 飞利浦灯具控股公司 | 用于优化至无线网格网络的节点的数据传输的系统和方法 |
| US8737244B2 (en) | 2010-11-29 | 2014-05-27 | Rosemount Inc. | Wireless sensor network access point and device RF spectrum analysis system and method |
| IL210169A0 (en) | 2010-12-22 | 2011-03-31 | Yehuda Binder | System and method for routing-based internet security |
| JP2012133690A (ja) * | 2010-12-24 | 2012-07-12 | Yokogawa Electric Corp | 無線フィールド機器、機器管理システム、及び機器管理方法 |
| US9282383B2 (en) | 2011-01-14 | 2016-03-08 | Trilliant Incorporated | Process, device and system for volt/VAR optimization |
| US8970394B2 (en) * | 2011-01-25 | 2015-03-03 | Trilliant Holdings Inc. | Aggregated real-time power outages/restoration reporting (RTPOR) in a secure mesh network |
| US9319894B2 (en) | 2011-01-25 | 2016-04-19 | Lg Electronics Inc. | Method for transmitting and receiving power outage report and device therefor |
| EP3285458B1 (en) | 2011-02-10 | 2022-10-26 | Trilliant Holdings, Inc. | Device and method for facilitating secure communications over a cellular network |
| US8861552B2 (en) * | 2011-02-15 | 2014-10-14 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Fault-tolerant self-stabilizing distributed clock synchronization protocol for arbitrary digraphs |
| WO2012114157A1 (en) * | 2011-02-25 | 2012-08-30 | Nokia Corporation | A method and an apparatus for a gateway |
| KR101794058B1 (ko) * | 2011-03-08 | 2017-12-04 | 삼성전자주식회사 | 간섭 회피를 위한 무선 네트워크 채널 할당 방법 |
| US9041349B2 (en) | 2011-03-08 | 2015-05-26 | Trilliant Networks, Inc. | System and method for managing load distribution across a power grid |
| US9735860B2 (en) * | 2011-03-18 | 2017-08-15 | Nokia Technologies Oy | Non-networked wireless communication |
| US8972524B2 (en) * | 2011-03-22 | 2015-03-03 | Elster Solutions, Llc | Internet protocol message routing over a wireless network of metering devices |
| US8842712B2 (en) | 2011-03-24 | 2014-09-23 | Gregory C. Hancock | Methods and apparatuses for reception of frequency-hopping spread spectrum radio transmissions |
| PL2503709T3 (pl) * | 2011-03-24 | 2014-01-31 | Panasonic Corp | System i metoda automatycznego odczytu licznika z ustawianiem czasu odczytu oraz nadrzędnymi, przekaźnikowymi i podległymi urządzeniami radiowymi do ich stosowania |
| US9037564B2 (en) | 2011-04-29 | 2015-05-19 | Stephen Lesavich | Method and system for electronic content storage and retrieval with galois fields on cloud computing networks |
| US9137250B2 (en) | 2011-04-29 | 2015-09-15 | Stephen Lesavich | Method and system for electronic content storage and retrieval using galois fields and information entropy on cloud computing networks |
| US9569771B2 (en) | 2011-04-29 | 2017-02-14 | Stephen Lesavich | Method and system for storage and retrieval of blockchain blocks using galois fields |
| US9361479B2 (en) | 2011-04-29 | 2016-06-07 | Stephen Lesavich | Method and system for electronic content storage and retrieval using Galois fields and geometric shapes on cloud computing networks |
| KR20120126448A (ko) * | 2011-05-11 | 2012-11-21 | 한국전자통신연구원 | 무선 네트워크 시스템에서의 동기 장치 및 방법 |
| GB2493901B (en) * | 2011-05-18 | 2014-01-08 | Onzo Ltd | Identification of a utility consumption event |
| US8509762B2 (en) | 2011-05-20 | 2013-08-13 | ReVerb Networks, Inc. | Methods and apparatus for underperforming cell detection and recovery in a wireless network |
| US8833390B2 (en) | 2011-05-31 | 2014-09-16 | Mueller International, Llc | Valve meter assembly and method |
| US8692538B2 (en) * | 2011-06-09 | 2014-04-08 | Teradyne, Inc. | Test equipment calibration |
| KR101756709B1 (ko) * | 2011-06-17 | 2017-07-11 | 삼성전자주식회사 | 데이터 관리 시스템 및 그 시스템에서 데이터 표시 방법 |
| WO2012177029A2 (ko) * | 2011-06-19 | 2012-12-27 | 엘지전자 주식회사 | Ｍ2ｍ 환경을 지원하는 무선접속시스템에서 비정상 정전 상황을 보고하기 위한 임의접속과정 수행방법 |
| US8966337B2 (en) * | 2011-06-20 | 2015-02-24 | Texas Instruments Incorporated | Powerline communication frames having CRC within header |
| US8509109B2 (en) * | 2011-06-27 | 2013-08-13 | Mitsubishi Electric Research Laboratories, Inc. | Method for discovering and maintaining routes in smart meter networks |
| US9113500B2 (en) * | 2011-07-10 | 2015-08-18 | Qualcomm Incorporated | Device and method for communication of management information in ad-hoc wireless networks |
| US9450642B2 (en) * | 2011-07-12 | 2016-09-20 | Cisco Technology, Inc. | Power conservation and latency minimization in frequency hopping communication networks |
| KR101264545B1 (ko) * | 2011-07-29 | 2013-05-14 | 한국전력공사 | 검침 데이터의 신뢰성 있는 전송을 보장하는 지능형 원격검침 시스템 및 이를 이용한 지능형 원격검침 방법 |
| US8954007B2 (en) * | 2011-08-12 | 2015-02-10 | Wicentric, Inc. | Systems and methods for low power short range wireless device communication scanning |
| US10382285B2 (en) * | 2011-08-25 | 2019-08-13 | Siemens Industry, Inc. | Smart grid communication assessment and co-simulation tool |
| US8874511B1 (en) * | 2011-09-06 | 2014-10-28 | Google Inc. | Efficient clearing of synchronization information |
| WO2013035104A1 (en) | 2011-09-07 | 2013-03-14 | Pathi Viraj Kumar | Intelligent coupler device for utility meter and method for operating thereof |
| EP2754271B1 (en) | 2011-09-09 | 2019-11-13 | Reverb Networks Inc. | Methods and apparatus for implementing a self optimizing-organizing network manager |
| TWI466486B (zh) * | 2011-09-16 | 2014-12-21 | Inst Information Industry | 行動台、基地台、通訊系統及其不正常斷電回報方法 |
| US9001787B1 (en) | 2011-09-20 | 2015-04-07 | Trilliant Networks Inc. | System and method for implementing handover of a hybrid communications module |
| EP2763046A4 (en) * | 2011-09-26 | 2015-09-09 | Murata Machinery Ltd | RELAY COMMUNICATION SYSTEM AND RELAY SERVER |
| US9739891B2 (en) | 2011-09-30 | 2017-08-22 | Echo Ridge Llc | System and method of using measurements of opportunity with vector tracking filters for improved navigation |
| US9594170B2 (en) | 2011-09-30 | 2017-03-14 | Echo Ridge Llc | Performance improvements for measurement of opportunity geolocation/navigation systems |
| WO2013052678A2 (en) * | 2011-10-04 | 2013-04-11 | Advanergy, Inc. | Battery management system and method |
| EP2581838A1 (en) * | 2011-10-14 | 2013-04-17 | Alcatel Lucent | Method for ranking messages |
| US10200476B2 (en) | 2011-10-18 | 2019-02-05 | Itron, Inc. | Traffic management and remote configuration in a gateway-based network |
| US8837640B2 (en) | 2011-10-21 | 2014-09-16 | Itron, Inc. | Multiple protocol receiver |
| US9197467B2 (en) | 2011-10-21 | 2015-11-24 | Itron, Inc. | Multiple protocol receiver |
| US8826265B2 (en) * | 2011-10-24 | 2014-09-02 | Texas Instruments Incorporated | Data concentrator initiated multicast firmware upgrade |
| US8855569B2 (en) * | 2011-10-27 | 2014-10-07 | Mueller International, Llc | Systems and methods for dynamic squelching in radio frequency devices |
| US8660134B2 (en) | 2011-10-27 | 2014-02-25 | Mueller International, Llc | Systems and methods for time-based hailing of radio frequency devices |
| US9007923B2 (en) | 2011-10-31 | 2015-04-14 | Itron, Inc. | Quick advertisement of a failure of a network cellular router |
| US8737378B2 (en) | 2011-10-31 | 2014-05-27 | Itron, Inc. | Synchronization of nodes in a network |
| ES2503568T3 (es) * | 2011-10-31 | 2014-10-07 | Itron, Inc. | Sincronización de los nodos en una red |
| KR20140092823A (ko) | 2011-11-08 | 2014-07-24 | 마벨 월드 트레이드 리미티드 | 파워에 기반한 네트워크 액세스 메커니즘 |
| US9258719B2 (en) | 2011-11-08 | 2016-02-09 | Viavi Solutions Inc. | Methods and apparatus for partitioning wireless network cells into time-based clusters |
| US8493868B2 (en) | 2011-11-11 | 2013-07-23 | Viet-Hung NGUYEN | Traffic load management |
| EP2592870B1 (en) * | 2011-11-11 | 2018-09-26 | Itron Global SARL | Routing communications based on node availability |
| US9014190B2 (en) | 2011-11-11 | 2015-04-21 | Itron, Inc. | Routing communications based on node availability |
| US8995361B2 (en) | 2011-11-11 | 2015-03-31 | Itron, Inc. | Multi-channel, multi-modulation, multi-rate communication with a radio transceiver |
| US20130132500A1 (en) | 2011-11-18 | 2013-05-23 | Apple Inc. | Selection of a master in a peer-to-peer network environment |
| US10271293B2 (en) | 2011-11-18 | 2019-04-23 | Apple Inc. | Group formation within a synchronized hierarchy of peer-to-peer devices |
| US9516615B2 (en) * | 2011-11-18 | 2016-12-06 | Apple Inc. | Selection of synchronization stations in a peer-to-peer network environment |
| WO2013078105A1 (en) * | 2011-11-22 | 2013-05-30 | Aclara Power-Line Systems Inc. | Metrology timekeeping systems and methods |
| CN102387042B (zh) * | 2011-11-22 | 2014-03-12 | 华为技术有限公司 | 自动配置的方法和系统以及网络节点 |
| US9148808B2 (en) | 2011-12-01 | 2015-09-29 | Echo Ridge Llc | Adaptive RF system testing system and method |
| JP5752807B2 (ja) * | 2011-12-09 | 2015-07-22 | 京セラ株式会社 | 電力制御装置、電力制御システム及び制御方法 |
| US8443105B1 (en) | 2011-12-12 | 2013-05-14 | The United States Of America As Represented By The Director, National Security Agency | Device for and method of network routing |
| US8755331B2 (en) * | 2011-12-13 | 2014-06-17 | International Business Machines Corporation | Determining a physical location of a wireless mobile device |
| US10075339B2 (en) | 2011-12-13 | 2018-09-11 | Tata Consultancy Services Limited | Generic device attributes for sensing devices |
| US20130155934A1 (en) * | 2011-12-16 | 2013-06-20 | Itron, Inc. | Network with secondary control channel |
| US8930455B2 (en) * | 2011-12-22 | 2015-01-06 | Silver Spring Networks, Inc. | Power outage detection system for smart grid using finite state machines |
| US9419888B2 (en) * | 2011-12-22 | 2016-08-16 | Itron, Inc. | Cell router failure detection in a mesh network |
| KR101901188B1 (ko) * | 2012-01-06 | 2018-09-27 | 삼성전자주식회사 | 무선 신체 영역 네트워크(ｗｂａｎ)에서 노드의 활동 구간을 재설정하기 위한 허브, 중계 노드, 노드 및 그 통신 방법 |
| US9380635B2 (en) | 2012-01-09 | 2016-06-28 | Google Technology Holdings LLC | Dynamic TCP layer optimization for real-time field performance |
| TWI571166B (zh) | 2012-01-13 | 2017-02-11 | 蘋果公司 | 在點對點網路環境中同步站台之選擇 |
| US9231657B2 (en) * | 2012-01-13 | 2016-01-05 | Texas Instruments Incorporated | Adaptive sub-band algorithm for point-to-point communication in PLC networks |
| US20130181845A1 (en) * | 2012-01-13 | 2013-07-18 | Itron, Inc. | Ami network with workforce management hotspot access |
| US8792406B2 (en) | 2012-01-30 | 2014-07-29 | Itron, Inc. | Data broadcasting with a prepare-to-broadcast message |
| US9565267B2 (en) | 2012-02-16 | 2017-02-07 | Philips Lighting Holding B.V. | Efficient proxy table management in communication networks |
| EP2815609A2 (en) * | 2012-02-16 | 2014-12-24 | Koninklijke Philips N.V. | Method for managing a proxy table in a wireless network using proxy devices |
| US9008722B2 (en) | 2012-02-17 | 2015-04-14 | ReVerb Networks, Inc. | Methods and apparatus for coordination in multi-mode networks |
| US8861565B2 (en) * | 2012-02-21 | 2014-10-14 | Elster Solutions, Llc | Scalable packets in a frequency hopping spread spectrum (FHSS) system |
| JP5782560B2 (ja) * | 2012-03-02 | 2015-09-24 | 富士通株式会社 | ノード及び通信制御方法 |
| US9167561B2 (en) * | 2012-03-12 | 2015-10-20 | Zte (Usa) Inc. | Sequence initialization for demodulation reference signal |
| US8902901B2 (en) | 2012-03-23 | 2014-12-02 | Itron, Inc. | Communication packet conversion |
| EP2660564B1 (en) * | 2012-05-04 | 2017-01-11 | Itron, Inc. | Verification of connection of meters to network |
| US9049692B2 (en) | 2012-04-13 | 2015-06-02 | Itron, Inc. | Hybrid access protocol for network nodes |
| EP2653992A1 (en) | 2012-04-17 | 2013-10-23 | Itron, Inc. | Microcontroller configured for external memory decryption |
| US9924242B2 (en) | 2012-04-20 | 2018-03-20 | Itron Global Sarl | Automatic network topology detection and fraud detection |
| US8755385B2 (en) | 2012-05-03 | 2014-06-17 | Itron, Inc. | Authentication using DHCP services in mesh networks |
| US9591525B2 (en) | 2012-05-03 | 2017-03-07 | Itron Global Sarl | Efficient device handover/migration in mesh networks |
| US9742644B2 (en) | 2012-05-04 | 2017-08-22 | Itron, Inc. | Verification of connection of meters to network |
| US9674589B2 (en) | 2012-05-04 | 2017-06-06 | Itron, Inc. | Coordinated collection of metering data |
| US9130843B2 (en) * | 2012-05-18 | 2015-09-08 | Alcatel Lucent | Method and apparatus for improving HTTP adaptive streaming performance using TCP modifications at content source |
| EP2670083B1 (en) | 2012-05-28 | 2015-05-06 | Itron, Inc. | Efficient multicast in a smart grid |
| US9231658B2 (en) | 2012-06-20 | 2016-01-05 | Texas Instruments Incorporated | Coexistence primitives in power line communication networks |
| CN102740428B (zh) * | 2012-06-20 | 2015-04-15 | 华为技术有限公司 | 调控发射功率的方法及无线路由设备 |
| EP2688322A1 (en) * | 2012-07-19 | 2014-01-22 | Alcatel Lucent | Protected broadcast in a warning message delivery chain |
| US9408251B2 (en) * | 2012-07-24 | 2016-08-02 | Mueller International, Llc | Transmitting data within a mesh network |
| US9047756B2 (en) | 2012-07-26 | 2015-06-02 | Mueller International, Llc | High traffic data transmission |
| US9047760B2 (en) * | 2012-07-26 | 2015-06-02 | Mueller International, Llc | High traffic data transmission |
| ES2541527T3 (es) | 2012-08-06 | 2015-07-21 | Itron, Inc. | Modulación múltiple multimedia y red mallada con múltiples tasas de datos |
| WO2014031237A1 (en) * | 2012-08-23 | 2014-02-27 | Itron, Inc. | Automated reconfiguration of utility meters |
| ES2588503T3 (es) | 2012-08-27 | 2016-11-03 | Itron, Inc. | Gestión de ancho de banda en una infraestructura de medición avanzada |
| US8867396B2 (en) * | 2012-08-31 | 2014-10-21 | Fujitsu Limtied | Method and system for last gasp device identification |
| US9088994B2 (en) | 2012-08-31 | 2015-07-21 | Fujitsu Limited | Method and system for last gasp device detection |
| US9438499B2 (en) * | 2012-09-06 | 2016-09-06 | Intel Corporation | Approximation of the physical location of devices and transitive device discovery through the sharing of neighborhood information using wireless or wired discovery mechanisms |
| EP2896173A4 (en) | 2012-09-11 | 2016-06-22 | Univ Washington Ct Commerciali | SENSOR NODES, DEVICES AND METHOD FOR THE WIRELESS TRANSMISSION OF DATA TO AN ENERGY INFRASTRUCTURE |
| US20140081659A1 (en) | 2012-09-17 | 2014-03-20 | Depuy Orthopaedics, Inc. | Systems and methods for surgical and interventional planning, support, post-operative follow-up, and functional recovery tracking |
| US9689710B2 (en) | 2012-09-21 | 2017-06-27 | Silver Spring Networks, Inc. | Power outage notification and determination |
| EP2898732B1 (en) * | 2012-09-24 | 2017-05-03 | Nec Corporation | Method and system for operating stations in a cooperative station network |
| US8908536B2 (en) * | 2012-09-28 | 2014-12-09 | Cisco Technology, Inc. | Density-based power outage notification transmission scheduling in frequency-hopping networks |
| US9479196B2 (en) | 2012-10-22 | 2016-10-25 | Intel Corporation | High performance interconnect link layer |
| US9280507B2 (en) | 2012-10-22 | 2016-03-08 | Intel Corporation | High performance interconnect physical layer |
| US9418035B2 (en) | 2012-10-22 | 2016-08-16 | Intel Corporation | High performance interconnect physical layer |
| US9148842B2 (en) * | 2012-10-24 | 2015-09-29 | Intel Corporation | Methods, wireless communication stations, and system for device-to-device discovery and advertisement |
| US9236904B2 (en) * | 2012-11-05 | 2016-01-12 | Cisco Technology, Inc. | Fast frequency-hopping schedule recovery |
| US9232411B2 (en) * | 2012-11-06 | 2016-01-05 | General Electric Company | Systems and methods for routing home area network (HAN) messages |
| NL2009801C2 (en) * | 2012-11-13 | 2014-05-14 | Lely Patent Nv | Network expansion method for a bluetooth network. |
| US9319310B2 (en) | 2012-11-15 | 2016-04-19 | Compass Electro Optical Systems Ltd. | Distributed switchless interconnect |
| US9008073B1 (en) * | 2012-12-07 | 2015-04-14 | Maxim Integrated Products, Inc. | Routing for power line communication systems |
| US9027035B2 (en) * | 2012-12-17 | 2015-05-05 | Itron, Inc. | Non real-time metrology data management |
| US9078050B2 (en) | 2012-12-28 | 2015-07-07 | Elster Solutions, Llc | Techniques for clock recovery in a mobile information collection network following a power outage |
| US9980114B2 (en) | 2013-03-15 | 2018-05-22 | Elwha Llc | Systems and methods for communication management |
| US9876762B2 (en) | 2012-12-31 | 2018-01-23 | Elwha Llc | Cost-effective mobile connectivity protocols |
| US9713013B2 (en) | 2013-03-15 | 2017-07-18 | Elwha Llc | Protocols for providing wireless communications connectivity maps |
| US9451394B2 (en) | 2012-12-31 | 2016-09-20 | Elwha Llc | Cost-effective mobile connectivity protocols |
| US9832628B2 (en) | 2012-12-31 | 2017-11-28 | Elwha, Llc | Cost-effective mobile connectivity protocols |
| US9635605B2 (en) | 2013-03-15 | 2017-04-25 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US8965288B2 (en) | 2012-12-31 | 2015-02-24 | Elwha Llc | Cost-effective mobile connectivity protocols |
| US9781664B2 (en) | 2012-12-31 | 2017-10-03 | Elwha Llc | Cost-effective mobile connectivity protocols |
| US9338130B2 (en) * | 2013-02-11 | 2016-05-10 | Broadcom Corporation | Apparatus and method to register Wi-Fi clients on a Wi-Fi network |
| US9014307B2 (en) | 2013-02-25 | 2015-04-21 | Itron, Inc. | Radio to analog-to-digital sample rate decoupled from digital subsystem |
| US9252998B2 (en) * | 2013-02-25 | 2016-02-02 | Itron, Inc. | Radio to detect and compensate for frequency misalignment |
| US9426680B2 (en) | 2013-02-25 | 2016-08-23 | Itron, Inc. | Real-time radio spectrum assessment engine |
| US8958506B2 (en) | 2013-02-25 | 2015-02-17 | Itron, Inc. | FSK/MSK decoder |
| US9077487B2 (en) | 2013-02-25 | 2015-07-07 | Itron, Inc. | Radio to support channel plans of arbitrary width and/or spacing |
| CN104023375B (zh) * | 2013-02-28 | 2017-06-23 | 株式会社理光 | 网络节点发现方法和装置 |
| EP2966631B1 (en) | 2013-03-07 | 2020-02-12 | Fujitsu Limited | Data collection method, system and data collection program |
| US9432251B2 (en) | 2013-03-08 | 2016-08-30 | Qualcomm Incorporated | Enhanced acknowledgement and retransmission mechanism |
| US9729943B2 (en) * | 2013-03-13 | 2017-08-08 | Trimble Inc. | Utility meter reporting network |
| US9706382B2 (en) | 2013-03-15 | 2017-07-11 | Elwha Llc | Protocols for allocating communication services cost in wireless communications |
| US9563218B2 (en) | 2013-03-15 | 2017-02-07 | Dominion Resources, Inc. | Electric power system control with measurement of energy demand and energy efficiency using t-distributions |
| US9596584B2 (en) | 2013-03-15 | 2017-03-14 | Elwha Llc | Protocols for facilitating broader access in wireless communications by conditionally authorizing a charge to an account of a third party |
| US9706060B2 (en) | 2013-03-15 | 2017-07-11 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US9553453B2 (en) | 2013-03-15 | 2017-01-24 | Dominion Resources, Inc. | Management of energy demand and energy efficiency savings from voltage optimization on electric power systems using AMI-based data analysis |
| US9781554B2 (en) | 2013-03-15 | 2017-10-03 | Elwha Llc | Protocols for facilitating third party authorization for a rooted communication device in wireless communications |
| US9678520B2 (en) | 2013-03-15 | 2017-06-13 | Dominion Resources, Inc. | Electric power system control with planning of energy demand and energy efficiency using AMI-based data analysis |
| US9843917B2 (en) | 2013-03-15 | 2017-12-12 | Elwha, Llc | Protocols for facilitating charge-authorized connectivity in wireless communications |
| US9807582B2 (en) | 2013-03-15 | 2017-10-31 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US9847639B2 (en) | 2013-03-15 | 2017-12-19 | Dominion Energy, Inc. | Electric power system control with measurement of energy demand and energy efficiency |
| WO2014144948A1 (en) * | 2013-03-15 | 2014-09-18 | Stuart Micheal D | Visible audiovisual annotation of infrared images using a separate wireless mobile device |
| US9582020B2 (en) | 2013-03-15 | 2017-02-28 | Dominion Resources, Inc. | Maximizing of energy delivery system compatibility with voltage optimization using AMI-based data control and analysis |
| US9813887B2 (en) | 2013-03-15 | 2017-11-07 | Elwha Llc | Protocols for facilitating broader access in wireless communications responsive to charge authorization statuses |
| US9693214B2 (en) | 2013-03-15 | 2017-06-27 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US9866706B2 (en) | 2013-03-15 | 2018-01-09 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| TW201505399A (zh) * | 2013-03-29 | 2015-02-01 | Vid Scale Inc | 早期封包損失檢測及回饋 |
| US9240934B2 (en) * | 2013-05-03 | 2016-01-19 | Landis+Gyr Innovations, Inc. | Monitoring the health of a home area network |
| KR101891005B1 (ko) | 2013-06-12 | 2018-08-22 | 콘비다 와이어리스, 엘엘씨 | 근접성 서비스들을 위한 콘텍스트 및 전력 제어 정보 관리 |
| US10230790B2 (en) * | 2013-06-21 | 2019-03-12 | Convida Wireless, Llc | Context management |
| US9904885B2 (en) | 2014-04-06 | 2018-02-27 | Vypin, LLC | Wireless medication compliance sensing device, system, and related methods |
| US20150130637A1 (en) * | 2013-11-11 | 2015-05-14 | Trackblue, Llc | Wireless Moisture Sensing Device, System, and Related Methods |
| US10121028B2 (en) | 2013-06-26 | 2018-11-06 | Vypin, LLC | Asset tag apparatus and related methods |
| US10572700B2 (en) | 2013-06-26 | 2020-02-25 | Vypin, LLC | Wireless asset location tracking system and related techniques |
| US10438476B2 (en) | 2013-06-26 | 2019-10-08 | Vypin, LLC | Wireless hand hygiene tracking system and related techniques |
| CN105431712B (zh) * | 2013-06-28 | 2018-10-09 | 飞利浦灯具控股公司 | 数据记录设备 |
| US10382059B2 (en) * | 2013-07-03 | 2019-08-13 | Samsung Electronics Co., Ltd. | Transmitting apparatus, encoding method thereof, receiving apparatus, and decoding method thereof |
| DK2822290T3 (da) * | 2013-07-03 | 2019-06-11 | Kamstrup As | Måleapparatnetværksnoder med beacon-signal omfattende signaldata |
| EP3020182B1 (en) | 2013-07-10 | 2020-09-09 | Convida Wireless, LLC | Context-aware proximity services |
| US9307427B2 (en) | 2013-07-22 | 2016-04-05 | Qualcomm Incorporated | Method and apparatus for use of a relay schemed to facilitate efficient broadcast communication in device to device environment |
| US9088983B2 (en) | 2013-08-06 | 2015-07-21 | Cisco Technology, Inc. | Interleaving low transmission power and medium transmission power channels in computer networks |
| US8891588B1 (en) | 2013-08-06 | 2014-11-18 | Cisco Technology, Inc. | On-demand medium to low transmission power channel switching in computer networks |
| US9172613B2 (en) | 2013-08-06 | 2015-10-27 | Cisco Technology, Inc. | Multiple topology routing architecture in computer networks |
| US9451558B2 (en) | 2013-08-20 | 2016-09-20 | Qualcomm Incorporated | Adaptive transmit power control in a communication network |
| US9631913B2 (en) | 2013-08-29 | 2017-04-25 | Mitutoyo Corporation | Calibration control device for metrology tools |
| IN2013MU02890A (pt) * | 2013-09-05 | 2015-07-03 | Tata Consultancy Services Ltd | |
| CN104519508B (zh) * | 2013-09-27 | 2018-05-04 | 上海诺基亚贝尔股份有限公司 | 用于设备到设备通信中的发现检测的方法和设备 |
| US9805208B2 (en) | 2013-09-30 | 2017-10-31 | Elwha Llc | Mobile device sharing facilitation methods and systems with recipient-dependent inclusion of a data selection |
| US9826439B2 (en) | 2013-09-30 | 2017-11-21 | Elwha Llc | Mobile device sharing facilitation methods and systems operable in network equipment |
| US9740875B2 (en) | 2013-09-30 | 2017-08-22 | Elwha Llc | Mobile device sharing facilitation methods and systems featuring exclusive data presentation |
| US9774728B2 (en) | 2013-09-30 | 2017-09-26 | Elwha Llc | Mobile device sharing facilitation methods and systems in a context of plural communication records |
| US9813891B2 (en) | 2013-09-30 | 2017-11-07 | Elwha Llc | Mobile device sharing facilitation methods and systems featuring a subset-specific source identification |
| US9838536B2 (en) | 2013-09-30 | 2017-12-05 | Elwha, Llc | Mobile device sharing facilitation methods and systems |
| US9231732B2 (en) * | 2013-10-07 | 2016-01-05 | Texas Instruments Incorporated | Packet header protection for utility networks |
| US9826412B2 (en) | 2013-10-24 | 2017-11-21 | At&T Intellectual Property I, L.P. | Facilitating adaptive key performance indicators in self-organizing networks |
| US8942134B1 (en) * | 2013-11-20 | 2015-01-27 | Magnolia Broadband Inc. | System and method for selective registration in a multi-beam system |
| TWI497438B (zh) | 2013-11-27 | 2015-08-21 | Ind Tech Res Inst | 先進讀表基礎建設中之韌體更新系統及其方法 |
| US9204405B2 (en) | 2013-12-09 | 2015-12-01 | Itron, Inc. | Synchronization methods and apparatus |
| US9781610B2 (en) * | 2013-12-18 | 2017-10-03 | Qualcomm Incorporated | Small cell clusters for signaling load reduction, time synchronization, KPI filtering and spectrum coordination |
| US9602270B2 (en) * | 2014-02-21 | 2017-03-21 | Landis+Gyr Innovations, Inc. | Clock drift compensation in a time synchronous channel hopping network |
| US11079417B2 (en) | 2014-02-25 | 2021-08-03 | Itron, Inc. | Detection of electric power diversion |
| US10571493B2 (en) | 2014-02-25 | 2020-02-25 | Itron, Inc. | Smart grid topology estimator |
| US9642071B2 (en) * | 2014-02-28 | 2017-05-02 | Qualcomm Incorporated | Access point initiated neighbor report request |
| US9369348B2 (en) * | 2014-03-10 | 2016-06-14 | Bank Of America Corporation | Outage reporting |
| US9772921B2 (en) * | 2014-03-17 | 2017-09-26 | Silver Spring Networks, Inc. | Techniques for collecting and analyzing notifications received from neighboring nodes across multiple channels |
| US20150271226A1 (en) * | 2014-03-18 | 2015-09-24 | Qualcomm Incorporated | Transport accelerator implementing a multiple interface architecture |
| US9271176B2 (en) | 2014-03-28 | 2016-02-23 | Magnolia Broadband Inc. | System and method for backhaul based sounding feedback |
| US10321379B2 (en) | 2014-04-16 | 2019-06-11 | Signify Holding B.V. | Method and apparatus for reducing the length of a packet storm in a wireless mesh network |
| US9602159B2 (en) * | 2014-05-01 | 2017-03-21 | Cisco Technology, Inc. | Communication channel identification in a power line communication network |
| US9350416B2 (en) * | 2014-05-07 | 2016-05-24 | Itron France | Frequency hopping sequence generation |
| US9494249B2 (en) | 2014-05-09 | 2016-11-15 | Mueller International, Llc | Mechanical stop for actuator and orifice |
| US10142847B2 (en) | 2014-05-23 | 2018-11-27 | Qualcomm Incorporated | Secure relay of discovery information in wireless networks |
| US10409920B1 (en) * | 2014-05-23 | 2019-09-10 | EMC IP Holding Company LLC | Data services for tiered memory |
| US10504148B2 (en) * | 2014-05-23 | 2019-12-10 | Qualcomm Incorporated | Peer-to-peer relaying of discovery information |
| DE102014008255A1 (de) | 2014-06-05 | 2015-12-17 | Diehl Metering Systems Gmbh | Funkübertragungssystem für Daten in lokalisierten Systemen und Verfahren zu seinem Betrieb |
| JP6544717B2 (ja) * | 2014-07-01 | 2019-07-17 | パナソニックＩｐマネジメント株式会社 | 電動工具システム |
| US10142444B2 (en) | 2014-07-01 | 2018-11-27 | Trinity Mobile Networks, Inc. | Methods, devices, and systems for implementing centralized hybrid wireless self-organizing networks |
| US10045291B2 (en) | 2014-07-16 | 2018-08-07 | Itron Global Sarl | Relay functionality of battery powered devices |
| US9860730B2 (en) * | 2014-07-16 | 2018-01-02 | Itron, Inc. | Network discovery by battery powered devices |
| WO2016011591A1 (en) * | 2014-07-21 | 2016-01-28 | Motorola Solutions, Inc. | Method and apparatus for subgroup call to group members missing a group call |
| US9614770B2 (en) * | 2014-07-21 | 2017-04-04 | Cisco Technology, Inc. | Network traffic control during limited power situations |
| JP6937685B2 (ja) * | 2014-08-15 | 2021-09-22 | インターデイジタル パテント ホールディングス インコーポレイテッド | Ｌｔｅシステムにおける低減能力ｗｔｒｕのためのランダムアクセスおよびページングの手順のサポート |
| US9565620B2 (en) | 2014-09-02 | 2017-02-07 | Mueller International, Llc | Dynamic routing in a mesh network |
| WO2016037324A1 (zh) * | 2014-09-10 | 2016-03-17 | 华为技术有限公司 | 数据传输链路建立装置、方法及通信系统 |
| GB2530272B (en) * | 2014-09-16 | 2020-10-07 | Nottingham Scient Limited | GNSS Jamming Signal Detection |
| US20160100400A1 (en) * | 2014-10-03 | 2016-04-07 | Qualcomm Incorporated | Beacon based time division multiplexing synchronization for multiple radio access technology coexistence |
| US9568522B2 (en) | 2014-10-20 | 2017-02-14 | Itron, Inc. | Electrical phase identification |
| ES2827698T3 (es) * | 2014-11-07 | 2021-05-24 | Nokia Solutions & Networks Oy | Transmisión de señales de referencia de descubrimiento en una portadora sin licencia en una red inalámbrica |
| US9781231B2 (en) | 2014-11-19 | 2017-10-03 | Itron, Inc. | Application platform operable on network node |
| US9835662B2 (en) | 2014-12-02 | 2017-12-05 | Itron, Inc. | Electrical network topology determination |
| US11329943B2 (en) * | 2014-12-17 | 2022-05-10 | Google Llc | Wireless network reliability over relatively low-power protocols |
| US10338996B2 (en) * | 2015-01-27 | 2019-07-02 | Nxp Usa, Inc. | Pipelined decoder and method for conditional storage |
| US10470161B2 (en) | 2015-02-06 | 2019-11-05 | Board Of Regents, The University Of Texas System | Method and system for measurement and characterization of channel delays for broadband power line communications |
| US20160242072A1 (en) * | 2015-02-18 | 2016-08-18 | Qualcomm Incorporated | Handling over-sized call setup messages |
| US9113353B1 (en) | 2015-02-27 | 2015-08-18 | ReVerb Networks, Inc. | Methods and apparatus for improving coverage and capacity in a wireless network |
| US9596558B2 (en) * | 2015-03-19 | 2017-03-14 | Texas Instruments Incorporated | Wireless sensor network and association request transmission method |
| US10834065B1 (en) | 2015-03-31 | 2020-11-10 | F5 Networks, Inc. | Methods for SSL protected NTLM re-authentication and devices thereof |
| US9838571B2 (en) | 2015-04-10 | 2017-12-05 | Gvbb Holdings S.A.R.L. | Precision timing for broadcast network |
| US10025344B2 (en) | 2015-04-21 | 2018-07-17 | The United States Of America As Represented By The Administrator Of Nasa | Self-stabilizing distributed symmetric-fault tolerant synchronization protocol |
| US10312681B2 (en) | 2015-05-28 | 2019-06-04 | Itron, Inc. | Automatic network device electrical phase identification |
| US10051346B2 (en) | 2015-06-17 | 2018-08-14 | Mueller International, Llc | Data communication using a private preamble |
| JP6415719B2 (ja) * | 2015-06-29 | 2018-10-31 | 三菱電機株式会社 | 無線機、中継機、通信システムおよび識別子割当方法 |
| US10292019B2 (en) * | 2015-07-07 | 2019-05-14 | M87, Inc. | Network methods and apparatus |
| US10732656B2 (en) | 2015-08-24 | 2020-08-04 | Dominion Energy, Inc. | Systems and methods for stabilizer control |
| US10231140B2 (en) * | 2015-09-24 | 2019-03-12 | Cisco Technology, Inc. | Self optimizing residential and community WiFi networks |
| US9992124B2 (en) | 2015-10-09 | 2018-06-05 | Itron, Inc. | Multi-channel decoder architecture |
| ITUB20155144A1 (it) * | 2015-10-16 | 2017-04-16 | Univ Degli Studi Di Roma La Sapienza Roma | ?metodo per gestire in modo adattivo e congiunto la politica di istradamento e la politica di ritrasmissione di un nodo in una rete sottomarina, ed i mezzi per la sua attuazione? |
| WO2017082719A1 (en) | 2015-11-12 | 2017-05-18 | Greenpeak Technologies B.V. | Concurrent multi-radio receiver |
| US10366359B2 (en) * | 2015-11-18 | 2019-07-30 | Microsoft Technology Licensing, Llc | Automatic extraction and completion of tasks associated with communications |
| US20170201558A1 (en) * | 2016-01-11 | 2017-07-13 | Hanwha Techwin Co., Ltd. | Method of managing a network and image obtaining apparatus |
| US10404698B1 (en) | 2016-01-15 | 2019-09-03 | F5 Networks, Inc. | Methods for adaptive organization of web application access points in webtops and devices thereof |
| WO2017127722A1 (en) | 2016-01-20 | 2017-07-27 | Lucent Medical Systems, Inc. | Low-frequency electromagnetic tracking |
| US10070403B2 (en) | 2016-03-09 | 2018-09-04 | Mueller International, Llc | Time beacons |
| US10362109B2 (en) * | 2016-03-30 | 2019-07-23 | Task Performance Group, Inc. | Cloud operating system and method |
| US10582347B2 (en) | 2016-04-14 | 2020-03-03 | Mueller International, Llc | SMS communication for cellular node |
| CN107306409B (zh) * | 2016-04-21 | 2020-06-12 | 富士通株式会社 | 参数确定方法、干扰分类识别方法及其装置 |
| US10097411B2 (en) | 2016-05-23 | 2018-10-09 | Mueller International, Llc | Node migration |
| CN105915276B (zh) * | 2016-05-31 | 2018-12-21 | 西安空间无线电技术研究所 | 星间距离大跨度变化星载tdma系统多速率业务时隙分配方法 |
| US10200947B2 (en) | 2016-07-11 | 2019-02-05 | Mueller International, Llc | Asymmetrical hail timing |
| US10292060B2 (en) | 2016-10-13 | 2019-05-14 | Eaton Intelligent Power Limited | Autonomous, power-dictated message routing for multi-hop mesh network outage communications |
| US10362374B2 (en) * | 2016-10-27 | 2019-07-23 | Itron, Inc. | Discovery mechanism for communication in wireless networks |
| GB201619640D0 (en) * | 2016-11-21 | 2017-01-04 | Jaguar Land Rover Ltd | Vehicle telematics messaging |
| US10379929B2 (en) | 2016-12-19 | 2019-08-13 | Microsoft Technology Licensing, Llc | Enhanced diagnostic and remediation system |
| US10788515B2 (en) | 2016-12-21 | 2020-09-29 | Itron, Inc. | Multi-piece current shunt with conductive channel for uniform current flow |
| US10401392B2 (en) | 2016-12-21 | 2019-09-03 | Itron, Inc. | Shunt thermocouple |
| GB2557992B (en) * | 2016-12-21 | 2021-08-18 | Texecom Ltd | Frequency hopping spread spectrum communication in mesh networks |
| US10554369B2 (en) | 2016-12-30 | 2020-02-04 | Itron, Inc. | Group acknowledgement message efficiency |
| US10104148B2 (en) * | 2017-01-03 | 2018-10-16 | Globalfoundries Inc. | Nanosecond accuracy under precision time protocol for ethernet by using high accuracy timestamp assist device |
| US10367529B2 (en) * | 2017-01-27 | 2019-07-30 | Hewlett Packard Enterprise Development Lp | List decode circuits |
| US10462759B2 (en) * | 2017-01-31 | 2019-10-29 | Dialog Semiconductor B.V. | System and method for clock synchronization on a wireless network |
| WO2018160124A1 (en) * | 2017-02-28 | 2018-09-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Frequency hopping pattern in a wireless communication system |
| CA2963434A1 (fr) | 2017-04-06 | 2018-10-06 | Hydro-Quebec | Verification de signal pour les compteurs communicants |
| US10178617B2 (en) | 2017-05-01 | 2019-01-08 | Mueller International, Llc | Hail and acceptance for battery-powered devices |
| US10499250B2 (en) | 2017-06-22 | 2019-12-03 | William Turner | RF client for implementing a hyper distribution communications protocol and maintaining a decentralized, distributed database among radio nodes |
| JP6874575B2 (ja) * | 2017-07-19 | 2021-05-19 | 沖電気工業株式会社 | 同期システム、通信装置、同期プログラム及び同期方法 |
| US10433197B2 (en) | 2017-07-20 | 2019-10-01 | Itron Networked Solutions, Inc. | Compensating for oscillator drift in wireless mesh networks |
| DE102017009564B4 (de) | 2017-07-20 | 2019-06-06 | Diehl Metering Systems Gmbh | Verfahren zum Verteilen von Daten |
| US10849086B2 (en) | 2017-07-20 | 2020-11-24 | Itron Networked Solutions, Inc. | Compensating for oscillator drift in wireless mesh networks |
| WO2019018190A1 (en) * | 2017-07-20 | 2019-01-24 | Itron Networked Solutions, Inc. | COMPENSATION OF OSCILLATOR DRIFT IN WIRELESS MESH NETWORKS |
| CN109428740B (zh) * | 2017-08-21 | 2020-09-08 | 华为技术有限公司 | 设备故障恢复的方法和装置 |
| CN107517069B (zh) * | 2017-08-22 | 2020-06-02 | 深圳市华信天线技术有限公司 | 跳频同步的方法、装置、接收机以及发射机 |
| CN108377505B (zh) * | 2017-09-26 | 2021-05-14 | 深圳市唐诚兴业科技有限公司 | Tdd-lte和fdd-lte手机上行信号侦测系统 |
| EP4102753A1 (en) | 2017-10-27 | 2022-12-14 | Telefonaktiebolaget LM Ericsson (publ) | Method and device for updating the number of retransmissions in a wireless mesh network |
| TWI646793B (zh) * | 2017-10-30 | 2019-01-01 | 財團法人工業技術研究院 | 達成通道互惠的校準方法及無線通訊裝置 |
| JP6906441B2 (ja) * | 2017-12-27 | 2021-07-21 | 三菱電機株式会社 | 停電検出システム |
| US10267652B1 (en) | 2018-01-23 | 2019-04-23 | Mueller International, Llc | Node communication with unknown network ID |
| US10382284B1 (en) * | 2018-03-02 | 2019-08-13 | SILVAIR Sp. z o.o. | System and method for commissioning mesh network-capable devices within a building automation and control system |
| US10659941B2 (en) | 2018-03-13 | 2020-05-19 | Cypress Semiconductor Corporation | Communicating packets in a mesh network |
| US11337136B2 (en) | 2018-04-24 | 2022-05-17 | Carrier Corporation | Automatic routing in a mesh network of wireless messaging devices |
| US11589287B2 (en) | 2018-04-24 | 2023-02-21 | Carrier Corporation | Automatic routing in a mesh network of wireless messaging devices |
| FR3081642B1 (fr) * | 2018-05-28 | 2020-09-04 | Sagemcom Energy & Telecom Sas | Procede de reenregistrement d'un compteur electrique intelligent |
| US10506653B1 (en) | 2018-05-30 | 2019-12-10 | Neptune Technology Group Inc. | Selection and use of different wireless networks by meter reading devices |
| US10833799B2 (en) | 2018-05-31 | 2020-11-10 | Itron Global Sarl | Message correction and dynamic correction adjustment for communication systems |
| US11477667B2 (en) | 2018-06-14 | 2022-10-18 | Mark Cummings | Using orchestrators for false positive detection and root cause analysis |
| US10911929B2 (en) * | 2018-07-13 | 2021-02-02 | Itron, Inc. | Power-efficient discovery process for nodes within a wireless mesh network |
| US11178530B2 (en) * | 2018-07-13 | 2021-11-16 | Itron, Inc. | Power-efficient discovery process for nodes within a wireless mesh network |
| CN109257706B (zh) * | 2018-08-10 | 2021-03-02 | Oppo广东移动通信有限公司 | 信息推送方法及相关设备 |
| CO2018008437A1 (es) * | 2018-08-11 | 2019-02-19 | Integrated Measurement Systems S A S | Dispositivo modular concentrador de datos para sistemas de medición de servicios públicos y proceso para la recolección y gestión de la información |
| US11523254B2 (en) | 2018-08-27 | 2022-12-06 | Signify Holding B.V. | Determining a suitability of network nodes for RF-based presence and/or location detection |
| CN112154696B (zh) | 2018-08-27 | 2023-07-18 | 谷歌有限责任公司 | 网状网络中的同步接收 |
| US10764770B2 (en) * | 2018-08-29 | 2020-09-01 | Landis+Gyr Innovations, Inc. | Detecting network devices without joining a network |
| CN109444571B (zh) * | 2018-09-21 | 2021-02-05 | 北京遥测技术研究所 | 一种小卫星通信载荷电磁兼容预测方法 |
| TWI684380B (zh) * | 2018-09-26 | 2020-02-01 | 啟碁科技股份有限公司 | 基於定位技術的無線網狀網路拓樸地圖的管理方法 |
| US10892858B2 (en) | 2018-09-28 | 2021-01-12 | At&T Intellectual Property I, L.P. | Chain broadcasting in vehicle-to-everything (V2X) communications |
| US11651453B2 (en) | 2018-10-19 | 2023-05-16 | Eaton Intelligent Power Limited | Enhanced status notification and outage detection systems and methods for electric utility networks |
| CN109360397A (zh) * | 2018-10-30 | 2019-02-19 | 国网北京市电力公司 | 多表集抄的方法、数据调度方法和多表集抄的系统 |
| EP3657672B1 (en) * | 2018-11-21 | 2022-08-10 | Nxp B.V. | Wireless receivers and related methods with random interferer immunity |
| US10820285B2 (en) * | 2018-11-26 | 2020-10-27 | Hitron Technologies Inc. | Method for network synchronization |
| US11012290B2 (en) | 2018-12-06 | 2021-05-18 | Landis+Gyr Innovations, Inc. | Systems and methods for node outage determination and reporting |
| US11128554B1 (en) * | 2019-02-01 | 2021-09-21 | Cisco Technology, Inc. | Increasing throughput for multi-PHY networks |
| JP7163507B2 (ja) * | 2019-02-15 | 2022-10-31 | シグニファイ ホールディング ビー ヴィ | Ｒｆベースの存在及び／又は位置検出機能を備えるノードを避けるネットワークルートの決定 |
| CN109831828A (zh) * | 2019-03-25 | 2019-05-31 | 宁夏隆基宁光仪表股份有限公司 | 一种网络拓扑结构的lora组网方法、装置及存储介质 |
| JP7211213B2 (ja) * | 2019-03-29 | 2023-01-24 | 株式会社デンソー | 中継装置、及び中継方法 |
| JP2020195084A (ja) * | 2019-05-29 | 2020-12-03 | ルネサスエレクトロニクス株式会社 | リレーノード、信号中継方法、および通信システム |
| US11125791B2 (en) * | 2019-05-30 | 2021-09-21 | Landis+Gyr Innovations, Inc. | Managing outage detections and reporting |
| CN110519330B (zh) * | 2019-07-23 | 2021-10-22 | 华东计算技术研究所（中国电子科技集团公司第三十二研究所） | 基于arinc661的多显控数据同步方法及系统 |
| CN110491111B (zh) * | 2019-07-24 | 2021-12-07 | 浙江华云信息科技有限公司 | 基于230MHz电力无线专网智能电表直采内置通信仓 |
| US11444805B2 (en) * | 2019-08-06 | 2022-09-13 | WiSilica Inc. | Secure over the air upload mechanism for wireless mesh nodes |
| CN110635994B (zh) * | 2019-09-30 | 2022-02-25 | 郑州信大捷安信息技术股份有限公司 | 一种基于自适应探测的异构互联系统及方法 |
| US11031938B2 (en) * | 2019-10-25 | 2021-06-08 | Cisco Technology, Inc. | Radio frequency synchronization in low-power and lossy networks |
| US11647033B2 (en) | 2019-11-21 | 2023-05-09 | International Business Machines Corporation | Device agnostic discovery and self-healing consensus network |
| CN110971269A (zh) * | 2019-12-19 | 2020-04-07 | 长园深瑞继保自动化有限公司 | 应用于配电故障指示系统的无线跳频自组网方法 |
| CN111698709B (zh) * | 2019-12-26 | 2023-04-07 | 重庆芯讯通无线科技有限公司 | 无线模块的通讯功能的测试方法、系统、介质及电子设备 |
| US11283935B2 (en) * | 2019-12-30 | 2022-03-22 | Texas Instruments Incorporated | Configurable circuit telemetry system |
| US11682094B2 (en) | 2020-01-13 | 2023-06-20 | Florida Power & Light Company | Public reporting of power line-down conditions |
| IT202000000490A1 (it) * | 2020-01-13 | 2021-07-13 | Pietro Fiorentini Spa | Apparecchio per la misurazione di un fluido. |
| FR3107632B1 (fr) | 2020-02-25 | 2022-02-04 | Commissariat Energie Atomique | Méthode de synchronisation de nœuds dans un réseau maillé déterministe |
| US10972958B1 (en) | 2020-03-05 | 2021-04-06 | At&T Intellectual Property I, L.P. | Location-based route management for vehicle-to-everything relay communications |
| CN111245663B (zh) * | 2020-03-16 | 2023-04-21 | 国网四川省电力公司成都供电公司 | 一种视频监控网络动态构建方法 |
| CN111355522B (zh) * | 2020-03-16 | 2022-03-08 | 纳瓦电子（上海）有限公司 | 无线级联系统 |
| US11562137B2 (en) | 2020-04-14 | 2023-01-24 | Bank Of America Corporation | System to correct model drift for natural language understanding |
| US11580456B2 (en) | 2020-04-27 | 2023-02-14 | Bank Of America Corporation | System to correct model drift in machine learning application |
| CN111641991B (zh) * | 2020-05-07 | 2022-02-08 | 西北工业大学 | 一种基于数据缓存的多中继两跳网络安全传输方法 |
| CN111798655B (zh) * | 2020-05-29 | 2021-12-10 | 国网江苏省电力有限公司信息通信分公司 | 一种适用于电力物联网台区的运行数据分钟级采集方法 |
| CN111970025B (zh) * | 2020-06-28 | 2022-06-14 | 上海伽易信息技术有限公司 | 地铁cbtc跳频信号全频段同步差分检测方法 |
| CN113923789B (zh) * | 2020-07-10 | 2023-08-18 | 中国移动通信集团浙江有限公司 | Lte载波调度装置及方法 |
| US11816730B2 (en) * | 2020-07-10 | 2023-11-14 | Charter Communications Operating, Llc | Low-latency trading platform and communications system |
| US11315183B2 (en) * | 2020-08-07 | 2022-04-26 | Hyannis Port Research, Inc. | Electronic trading system and method based on point-to-point mesh architecture |
| US11683199B2 (en) | 2020-08-07 | 2023-06-20 | Hyannis Port Research, Inc. | Distributed system with fault tolerance and self-maintenance |
| US11483087B2 (en) | 2020-08-07 | 2022-10-25 | Hyannis Port Research, Inc. | Systems and methods for clock synchronization using special physical layer clock sync symbols |
| US11328357B2 (en) | 2020-08-07 | 2022-05-10 | Hyannis Port Research, Inc. | Sequencer bypass with transactional preprocessing in distributed system |
| US11303389B2 (en) | 2020-08-07 | 2022-04-12 | Hyannis Port Research, Inc. | Systems and methods of low latency data communication for physical link layer reliability |
| US11228529B1 (en) | 2020-08-07 | 2022-01-18 | Hyannis Port Research, Inc. | Local and global quality of service shaper on ingress in a distributed system |
| US11088959B1 (en) | 2020-08-07 | 2021-08-10 | Hyannis Port Research, Inc. | Highly deterministic latency in a distributed system |
| CN111940954B (zh) * | 2020-08-14 | 2022-04-08 | 南京水木自动化科技有限公司 | 高可靠抗弧光干扰的焊接多形态数据智能处理方法 |
| CN112073920B (zh) * | 2020-09-15 | 2022-08-26 | 杭州萤石软件有限公司 | 一种无线网格网络节点的组网方法、网络节点设备 |
| CN112382076B (zh) * | 2020-11-12 | 2021-08-27 | 贵州电网有限责任公司 | 一种台区电能表拓扑信息获取设备和操作方法 |
| CN113034882B (zh) * | 2020-12-23 | 2022-02-22 | 利尔达科技集团股份有限公司 | 一种基于分时间片竞争上报的集抄方法 |
| US20220272775A1 (en) * | 2021-02-25 | 2022-08-25 | Charter Communications Operating, Llc | Device address bundling for iot communication |
| EP4309376A1 (en) | 2021-03-15 | 2024-01-24 | Northq Aps | A data forwarding element and a method of controlling it |
| US20220322271A1 (en) * | 2021-04-02 | 2022-10-06 | Booz Allen Hamilton Inc. | Systems and methods for managing antenna systems |
| US11632712B2 (en) * | 2021-04-28 | 2023-04-18 | Qualcomm Incorporated | System information parameter update time in non-terrestrial network |
| US11824634B2 (en) | 2021-05-20 | 2023-11-21 | Itron, Inc. | Unicast transmissions in mesh network nodes |
| US11764891B2 (en) * | 2021-05-20 | 2023-09-19 | Itron, Inc. | Time synchronization of mesh network nodes |
| US11546831B1 (en) * | 2021-06-16 | 2023-01-03 | Meta Platforms, Inc. | Closing open loops of wireless mesh networks |
| US11496921B1 (en) | 2021-08-05 | 2022-11-08 | Bmic Llc | Computer-based systems configured for managing mesh networks having integrated roofing components and methods of use thereof |
| WO2023014915A1 (en) | 2021-08-05 | 2023-02-09 | Bmic Llc | Computer-based systems configured for managing mesh networks having integrated roofing components and methods of use thereof |
| US11924077B2 (en) * | 2021-08-13 | 2024-03-05 | Itron, Inc. | Determining network reliability using message success rates |
| US11483224B1 (en) | 2021-08-13 | 2022-10-25 | Itron, Inc. | Determining network reliability using message success rates |
| CN114007243A (zh) * | 2021-10-29 | 2022-02-01 | 重庆邮电大学 | 一种宽带微功率网络性能在线分析系统与方法 |
| WO2023147181A1 (en) * | 2022-01-31 | 2023-08-03 | Booz Allen Hamilton Inc. | Edge based routing software instance, device and method |
| US11734525B1 (en) * | 2022-03-11 | 2023-08-22 | Sankalp Sandeep Modi | Voice programmable automatic identification and data capture system with reduced physical tags |
| CN115277331B (zh) * | 2022-06-17 | 2023-09-12 | 哲库科技(北京)有限公司 | 信号补偿方法及装置、调制解调器、通信设备、存储介质 |
| US11601505B1 (en) | 2022-08-13 | 2023-03-07 | Uab 360 It | Communication functions in a mesh network |
Family Cites Families (346)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US43059A (en) * | 1864-06-07 | Improvement in spindle-bolsters for spinning-machines | ||
| US129005A (en) * | 1872-07-16 | Improvement in portable steam-engines | ||
| US88083A (en) * | 1869-03-23 | Improvement in blast, smelting, and cupola furnaces | ||
| US43860A (en) * | 1864-08-16 | Improvement in the manufacture of paper | ||
| US24235A (en) * | 1859-05-31 | jl alexander e | ||
| US4555A (en) * | 1846-05-30 | Botary steam-engine | ||
| US52290A (en) * | 1866-01-30 | Improvement in artificial teeth | ||
| US190055A (en) * | 1877-04-24 | Improvement in the manufacture of shovel-blanks | ||
| US271006A (en) * | 1883-01-23 | James a | ||
| US78029A (en) * | 1868-05-19 | James t | ||
| US172024A (en) * | 1876-01-11 | Improvement in lawn-sprinklers | ||
| US53639A (en) * | 1866-04-03 | Improved car-coupling | ||
| US85928A (en) * | 1869-01-19 | Improvement in fen-holders | ||
| US192415A (en) * | 1877-06-26 | Improvement in apparatus for loading and unloading wagons | ||
| US62224A (en) * | 1867-02-19 | B rawsof | ||
| US218616A (en) * | 1879-08-19 | Improvement in fire-backs | ||
| US8663A (en) * | 1852-01-13 | Turning prisms | ||
| US201397A (en) * | 1878-03-19 | Improvement in steam-engines for cotton-presses | ||
| US548526A (en) * | 1895-10-22 | Valve releasing gear | ||
| US103486A (en) * | 1870-05-24 | Improved clothes-drier | ||
| US61623A (en) * | 1867-01-29 | William c | ||
| US74015A (en) * | 1868-02-04 | District of | ||
| US171696A (en) * | 1876-01-04 | Improvement in gage-lathes | ||
| US63723A (en) * | 1867-04-09 | hudson | ||
| US218873A (en) * | 1879-08-26 | Improvement in electric telephones | ||
| US243867A (en) * | 1881-07-05 | Elihtj dodds | ||
| US179149A (en) * | 1876-06-27 | Improvement in seeding-machines | ||
| US19725A (en) * | 1858-03-23 | Improvement irj plows | ||
| US38548A (en) * | 1863-05-19 | Improvement in railroad-rails | ||
| US163144A (en) * | 1875-05-11 | Improvement in ice-machines | ||
| US12935A (en) * | 1855-05-22 | Francis s | ||
| US146985A (en) * | 1874-02-03 | Improvement in compositions for cornices | ||
| US226179A (en) * | 1880-04-06 | Wagon-seat | ||
| US52328A (en) * | 1866-01-30 | Improved mode of attaching car-wheels to axles | ||
| US48199A (en) * | 1865-06-13 | Machine for printing paper-hangings | ||
| US278440A (en) * | 1883-05-29 | leland | ||
| US43961A (en) * | 1864-08-30 | Improvement in fliers for spinning-frames | ||
| US93484A (en) * | 1869-08-10 | Improved carriage-jack | ||
| US147097A (en) * | 1874-02-03 | Improvement in machines for gluing moldings | ||
| US1492328A (en) * | 1921-09-24 | 1924-04-29 | James S Lang | Shock absorber |
| US3127958A (en) * | 1961-06-30 | 1964-04-07 | Ford Motor Co | Shock absorber with improved relief valve structure |
| US3892298A (en) * | 1974-02-13 | 1975-07-01 | Leland F Blatt | Variable orifice shock absorber |
| US4126302A (en) * | 1978-01-20 | 1978-11-21 | Curnutt Charles R | Horizontal inertia-responsive shock absorber |
| US4214737A (en) * | 1979-05-11 | 1980-07-29 | Blatt Leland F | Adjustable shock absorber including metering pin and reservoir structure |
| US5005142A (en) * | 1987-01-30 | 1991-04-02 | Westinghouse Electric Corp. | Smart sensor system for diagnostic monitoring |
| US4799062A (en) | 1987-04-27 | 1989-01-17 | Axonn Corporation | Radio position determination method and apparatus |
| EP0318817A3 (de) * | 1987-11-28 | 1990-05-30 | Hermann Hemscheidt Maschinenfabrik GmbH & Co. | Hydro-pneumatischer Stoss- und Schwingungsdämpfer mit Innenrohr |
| CA1335836C (en) * | 1988-07-07 | 1995-06-06 | Ichiro Iida | Adaptive routing system |
| US4998102A (en) * | 1988-08-02 | 1991-03-05 | Distribution Control Systems, Inc. | Integrated meter transponder |
| US5167035A (en) * | 1988-09-08 | 1992-11-24 | Digital Equipment Corporation | Transferring messages between nodes in a network |
| US4977577A (en) | 1988-11-02 | 1990-12-11 | Axonn Corporation | Wireless alarm system |
| US5987058A (en) | 1988-11-02 | 1999-11-16 | Axonn Corporation | Wireless alarm system |
| US5067136A (en) | 1988-11-02 | 1991-11-19 | Axonn Corporation | Wireless alarm system |
| US5095493A (en) * | 1988-11-02 | 1992-03-10 | Axonn Corporation | Wireless alarm system |
| US5658828A (en) * | 1989-11-30 | 1997-08-19 | Sgs-Thomson Microelectronics, Inc. | Method for forming an aluminum contact through an insulating layer |
| US5553094A (en) * | 1990-02-15 | 1996-09-03 | Iris Systems, Inc. | Radio communication network for remote data generating stations |
| USRE35829E (en) | 1990-08-27 | 1998-06-23 | Axonn Corporation | Binary phase shift keying modulation system and/or frequency multiplier |
| US5119396A (en) | 1990-08-27 | 1992-06-02 | Axonn Corporation | Binary phase shift keying modulation system |
| US5198796A (en) * | 1991-06-27 | 1993-03-30 | Distribution Control Systems, Inc. | Outbound signal detector system and method |
| US5604768A (en) | 1992-01-09 | 1997-02-18 | Cellnet Data Systems, Inc. | Frequency synchronized bidirectional radio system |
| US5377232A (en) | 1992-01-09 | 1994-12-27 | Cellnet Data Systems, Inc. | Frequency synchronized bidirectional radio system |
| US5598903A (en) * | 1992-05-05 | 1997-02-04 | Ricor Racing & Development, L.P. | Acceleration sensitive flow sensitive mcpherson strut |
| WO1994028663A1 (en) | 1992-05-08 | 1994-12-08 | Axonn Corporation | A frequency agile radio |
| US5311541A (en) * | 1992-05-08 | 1994-05-10 | Axonn Corporation | Frequency agile radio |
| US5668828A (en) * | 1992-05-08 | 1997-09-16 | Sanconix, Inc. | Enhanced frequency agile radio |
| US5310075A (en) | 1992-11-27 | 1994-05-10 | Distribution Control Systems, Inc. | Waterproof, gasketless enclosure |
| US5486805A (en) | 1993-07-06 | 1996-01-23 | Distribution Control Systems, Inc. | Method of receiving unsolicited messages on an electrical distribution network communications system |
| US5368141A (en) * | 1993-12-27 | 1994-11-29 | Ford Motor Company | Displacement sensitive valve mechanism |
| US5457713A (en) | 1994-03-07 | 1995-10-10 | Sanconix, Inc. | Spread spectrum alignment repositioning method |
| US5696441A (en) | 1994-05-13 | 1997-12-09 | Distribution Control Systems, Inc. | Linear alternating current interface for electronic meters |
| US5509027A (en) | 1994-12-05 | 1996-04-16 | Motorola, Inc. | Synchronization method in a frequency hopping local area network having dedicated control channels |
| US5656993A (en) * | 1995-05-08 | 1997-08-12 | Semisystems, Inc. | Vehicle wheel condition monitor and data storage system |
| SE512020C2 (sv) * | 1995-05-18 | 2000-01-17 | Oehlins Racing Ab | Anordning vid stötdämpare |
| US5661750A (en) | 1995-06-06 | 1997-08-26 | Cellnet Data Systems, Inc. | Direct sequence spread spectrum system |
| US5920589A (en) | 1995-06-07 | 1999-07-06 | Sanconix Inc. | Direct sequence spread spectrum DSP system |
| CA2224238A1 (en) | 1995-06-15 | 1997-01-03 | Hall, David | Communication system for superimposing data onto a video signal |
| US5626755A (en) | 1995-11-08 | 1997-05-06 | Micronair, Inc. | Method and apparatus for waste digestion using multiple biological processes |
| US5907559A (en) * | 1995-11-09 | 1999-05-25 | The United States Of America As Represented By The Secretary Of Agriculture | Communications system having a tree structure |
| US6088689A (en) | 1995-11-29 | 2000-07-11 | Hynomics Corporation | Multiple-agent hybrid control architecture for intelligent real-time control of distributed nonlinear processes |
| US6195018B1 (en) | 1996-02-07 | 2001-02-27 | Cellnet Data Systems, Inc. | Metering system |
| JP2803716B2 (ja) * | 1996-03-11 | 1998-09-24 | 日本電気株式会社 | Ｃｄｍａセルラーシステムにおける無線回線制御装置 |
| US5833036A (en) * | 1996-03-20 | 1998-11-10 | Pro-Formance Shocks, Inc. | Rebound adjustable shock absorber |
| US6174992B1 (en) * | 1997-03-21 | 2001-01-16 | Human Genome Sciences, Inc. | Human endometrial specific steroid-binding factor I, II and III |
| US6078251A (en) | 1996-03-27 | 2000-06-20 | Intermec Ip Corporation | Integrated multi-meter and wireless communication link |
| US6765904B1 (en) * | 1999-08-10 | 2004-07-20 | Texas Instruments Incorporated | Packet networks |
| US5812547A (en) | 1996-08-22 | 1998-09-22 | At&T Corp. | System and method for dynamic time division access |
| US5907491A (en) | 1996-08-23 | 1999-05-25 | Csi Technology, Inc. | Wireless machine monitoring and communication system |
| US6246677B1 (en) | 1996-09-06 | 2001-06-12 | Innovatec Communications, Llc | Automatic meter reading data communication system |
| US6044062A (en) | 1996-12-06 | 2000-03-28 | Communique, Llc | Wireless network system and method for providing same |
| US7054271B2 (en) * | 1996-12-06 | 2006-05-30 | Ipco, Llc | Wireless network system and method for providing same |
| AR011440A1 (es) | 1997-02-12 | 2000-08-16 | Abb Power T & D Co | DISPOSICIoN DE MEDICIoN ELECTRONICA |
| US6900737B1 (en) | 1997-02-12 | 2005-05-31 | Elster Electricity, Llc | Remote access to electronic meters using the short message service |
| US7046682B2 (en) * | 1997-02-12 | 2006-05-16 | Elster Electricity, Llc. | Network-enabled, extensible metering system |
| US6430268B1 (en) | 1997-09-20 | 2002-08-06 | Statsignal Systems, Inc. | Systems for requesting service of a vending machine |
| US6233327B1 (en) | 1997-02-14 | 2001-05-15 | Statsignal Systems, Inc. | Multi-function general purpose transceiver |
| US5926531A (en) * | 1997-02-14 | 1999-07-20 | Statsignal Systems, Inc. | Transmitter for accessing pay-type telephones |
| US6618578B1 (en) | 1997-02-14 | 2003-09-09 | Statsignal Systems, Inc | System and method for communicating with a remote communication unit via the public switched telephone network (PSTN) |
| US7079810B2 (en) | 1997-02-14 | 2006-07-18 | Statsignal Ipc, Llc | System and method for communicating with a remote communication unit via the public switched telephone network (PSTN) |
| US6628764B1 (en) | 1997-02-14 | 2003-09-30 | Statsignal Systems, Inc. | System for requesting service of a vending machine |
| NL1005765C2 (nl) * | 1997-04-08 | 1998-10-09 | Koni Bv | Dubbelwerkende demper met stangslag-volumecompensatie. |
| US5963650A (en) * | 1997-05-01 | 1999-10-05 | Simionescu; Dan | Method and apparatus for a customizable low power RF telemetry system with high performance reduced data rate |
| US5999561A (en) | 1997-05-20 | 1999-12-07 | Sanconix, Inc. | Direct sequence spread spectrum method, computer-based product, apparatus and system tolerant to frequency reference offset |
| US6178197B1 (en) | 1997-06-23 | 2001-01-23 | Cellnet Data Systems, Inc. | Frequency discrimination in a spread spectrum signal processing system |
| US6456644B1 (en) | 1997-06-23 | 2002-09-24 | Cellnet Data Systems, Inc. | Bandpass correlation of a spread spectrum signal |
| US6047016A (en) | 1997-06-23 | 2000-04-04 | Cellnet Data Systems, Inc. | Processing a spread spectrum signal in a frequency adjustable system |
| US6263009B1 (en) | 1997-06-23 | 2001-07-17 | Cellnet Data Systems, Inc. | Acquiring a spread spectrum signal |
| US6349094B1 (en) | 1997-07-03 | 2002-02-19 | Mdiversity Inc. | Method and apparatus for wireless communications employing control for broadcast transmission |
| JP3070735B2 (ja) * | 1997-07-23 | 2000-07-31 | 株式会社日立製作所 | 摩擦攪拌接合方法 |
| US6538577B1 (en) | 1997-09-05 | 2003-03-25 | Silver Springs Networks, Inc. | Electronic electric meter for networked meter reading |
| US6617879B1 (en) | 1997-09-17 | 2003-09-09 | Sony Corporation | Transparently partitioned communication bus for multi-port bridge for a local area network |
| US5933072A (en) * | 1997-11-07 | 1999-08-03 | Distribution Control Systems, Inc. | Current level control for TWACS inbound communications |
| JP2001523855A (ja) | 1997-11-14 | 2001-11-27 | マラソン テクノロジーズ コーポレイション | 故障回復／耐故障計算機 |
| JPH11205845A (ja) * | 1998-01-14 | 1999-07-30 | Locus:Kk | 位置特定システム |
| US6100816A (en) * | 1998-01-16 | 2000-08-08 | Cellnet Data Systems, Inc. | Utility meter adapter |
| SG77163A1 (en) * | 1998-03-06 | 2000-12-19 | John Francis Chong | A method of implementing an acyclic directed graph structure using a relational database |
| US6400361B2 (en) * | 1998-04-23 | 2002-06-04 | United Technologies Dearborn, Inc | Graphics processor architecture employing variable refresh rates |
| US6778099B1 (en) | 1998-05-01 | 2004-08-17 | Elster Electricity, Llc | Wireless area network communications module for utility meters |
| US6914893B2 (en) | 1998-06-22 | 2005-07-05 | Statsignal Ipc, Llc | System and method for monitoring and controlling remote devices |
| US6914533B2 (en) * | 1998-06-22 | 2005-07-05 | Statsignal Ipc Llc | System and method for accessing residential monitoring devices |
| US6437692B1 (en) | 1998-06-22 | 2002-08-20 | Statsignal Systems, Inc. | System and method for monitoring and controlling remote devices |
| US6218953B1 (en) * | 1998-10-14 | 2001-04-17 | Statsignal Systems, Inc. | System and method for monitoring the light level around an ATM |
| US6891838B1 (en) | 1998-06-22 | 2005-05-10 | Statsignal Ipc, Llc | System and method for monitoring and controlling residential devices |
| US6028522A (en) | 1998-10-14 | 2000-02-22 | Statsignal Systems, Inc. | System for monitoring the light level around an ATM |
| US6784806B1 (en) | 1998-06-29 | 2004-08-31 | General Electric Company | Electronic electricity meter |
| US6505253B1 (en) * | 1998-06-30 | 2003-01-07 | Sun Microsystems | Multiple ACK windows providing congestion control in reliable multicast protocol |
| US6204808B1 (en) | 1998-08-13 | 2001-03-20 | Ericsson Inc. | Method and system for aiding GPS receivers via a cellular or PCS network |
| US6304759B1 (en) * | 1998-08-31 | 2001-10-16 | Lucent Technologies Inc. | Method for extending the range of a wireless communication system |
| US6414605B1 (en) | 1998-09-02 | 2002-07-02 | Schlumberger Resource Management Services, Inc. | Utility meter pit lid mounted antenna assembly and method |
| AU6106399A (en) | 1998-09-29 | 2000-04-17 | Scientific Generics Limited | Magnetic flow meter |
| US6591229B1 (en) * | 1998-10-09 | 2003-07-08 | Schlumberger Industries, Sa | Metrology device with programmable smart card |
| US7103511B2 (en) | 1998-10-14 | 2006-09-05 | Statsignal Ipc, Llc | Wireless communication networks for providing remote monitoring of devices |
| US6232885B1 (en) | 1998-10-15 | 2001-05-15 | Schlumberger Resource Management Services, Inc. | Electricity meter |
| US6952408B2 (en) | 1998-10-15 | 2005-10-04 | Airnet Communications Corporation | Method of baseband frequency hopping utilizing time division multiplexed mapping between a radio transceiver and digital signal processing resources |
| US6700902B1 (en) | 1998-10-19 | 2004-03-02 | Elster Electricity, Llc | Method and system for improving wireless data packet delivery |
| US6826616B2 (en) * | 1998-10-30 | 2004-11-30 | Science Applications International Corp. | Method for establishing secure communication link between computers of virtual private network |
| US6424270B1 (en) | 1998-10-30 | 2002-07-23 | Schlumberger Resource Management Services, Inc. | Utility meter interface unit |
| CA2723504C (en) * | 1998-10-30 | 2014-04-29 | Virnetx, Inc. | An agile network protocol for secure communications with assured system availability |
| US6502135B1 (en) * | 1998-10-30 | 2002-12-31 | Science Applications International Corporation | Agile network protocol for secure communications with assured system availability |
| SE515321C2 (sv) * | 1998-12-02 | 2001-07-16 | Oehlins Racing Ab | Stötdämpare med cylinder innefattande en kolvstång med minst två kolvar |
| US6321271B1 (en) * | 1998-12-22 | 2001-11-20 | Lucent Technologies Inc. | Constrained shortest path routing method |
| CA2356947A1 (en) | 1998-12-23 | 2000-07-06 | Nokia Wireless Routers, Inc. | A unified routing scheme for ad-hoc internetworking |
| US6377609B1 (en) * | 1999-03-05 | 2002-04-23 | Neptune Technology Group Inc. | Spread spectrum frequency hopping system and method |
| US6747557B1 (en) * | 1999-03-18 | 2004-06-08 | Statsignal Systems, Inc. | System and method for signaling a weather alert condition to a residential environment |
| US20040183687A1 (en) | 1999-03-18 | 2004-09-23 | Petite Thomas D. | System and method for signaling a weather alert condition to a residential environment |
| US6621796B1 (en) * | 1999-03-22 | 2003-09-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Discard mechanism for selective repeat automatic repeat request |
| US6267400B1 (en) * | 1999-04-06 | 2001-07-31 | Specialized Bicycle Components, Inc. | Bicycle damping enhancement system |
| US20010024165A1 (en) * | 1999-04-09 | 2001-09-27 | Steen Henry B. | Lan/wan automatic sensor reading system |
| US6163276A (en) | 1999-05-17 | 2000-12-19 | Cellnet Data Systems, Inc. | System for remote data collection |
| US6181258B1 (en) | 1999-05-17 | 2001-01-30 | Cellnet Data Systems, Inc. | Receiver capable of parallel demodulation of messages |
| US6452986B1 (en) | 1999-05-17 | 2002-09-17 | Cellnet Data Systems, Inc. | Detector tolerant of frequency misalignment |
| AU5158800A (en) * | 1999-05-28 | 2000-12-18 | Basic Resources, Inc. | Wireless transceiver network employing node-to-node data messaging |
| US7606164B2 (en) | 1999-12-14 | 2009-10-20 | Texas Instruments Incorporated | Process of increasing source rate on acceptable side of threshold |
| US7020701B1 (en) | 1999-10-06 | 2006-03-28 | Sensoria Corporation | Method for collecting and processing data using internetworked wireless integrated network sensors (WINS) |
| US6885309B1 (en) | 2000-06-01 | 2005-04-26 | Cellnet Innovations, Inc. | Meter to internet pathway |
| US6894975B1 (en) | 2000-01-15 | 2005-05-17 | Andrzej Partyka | Synchronization and access of the nodes in a communications network |
| US6369769B1 (en) | 2000-02-25 | 2002-04-09 | Innovatec Communications, Llc | Flush mounted pit lid antenna |
| US20020010641A1 (en) * | 2000-05-02 | 2002-01-24 | Stevens Jessica L. | Low cost system method apparatus and way of doing business for the conveyance and electronic labeling and transference of secure multimedia and data products |
| US6735178B1 (en) | 2000-05-10 | 2004-05-11 | Ricochet Networks, Inc. | Method for maximizing throughput for multiple links using directional elements |
| US6426027B1 (en) * | 2000-05-17 | 2002-07-30 | Neptune Technology Group, Inc. | Method of injection molding for creating a fluid meter housing |
| US6604434B1 (en) | 2000-06-23 | 2003-08-12 | Neptune Technology Group, Inc. | Method and apparatus for determining the direction and rate of a rotating element |
| US6928263B2 (en) * | 2000-06-26 | 2005-08-09 | Koninklijke Philips Electronics N.V. | Local data delivery through beacons |
| US7031945B1 (en) * | 2000-07-24 | 2006-04-18 | Donner Irah H | System and method for reallocating and/or upgrading and/or rewarding tickets, other event admittance means, goods and/or services |
| WO2002013412A1 (en) | 2000-08-09 | 2002-02-14 | Statsignal Systems, Inc. | Systems and methods for providing remote monitoring of electricity consumption for an electric meter |
| US6741856B2 (en) | 2000-08-14 | 2004-05-25 | Vesuvius Inc. | Communique system for virtual private narrowcasts in cellular communication networks |
| US6774981B1 (en) * | 2000-09-08 | 2004-08-10 | Nikon Corporation | Modular exposure apparatus with removable optical device and improved isolation of the optical device |
| US7031288B2 (en) * | 2000-09-12 | 2006-04-18 | Sri International | Reduced-overhead protocol for discovering new neighbor nodes and detecting the loss of existing neighbor nodes in a network |
| US6918311B2 (en) | 2000-09-22 | 2005-07-19 | M&Fc Holding, Llc | Weather resistant automatic meter reading unit |
| WO2002030140A2 (en) * | 2000-10-06 | 2002-04-11 | Telemetry Technologies, Inc. | System and method for hierarchical network for use in remote data sensing |
| US6685309B2 (en) * | 2000-10-06 | 2004-02-03 | Seiko Epson Corporation | Geometric ink channels for ink cartridge |
| US9173175B2 (en) | 2000-11-16 | 2015-10-27 | Sony Corporation | Information processing apparatus and communication apparatus |
| SE519560C2 (sv) * | 2000-12-20 | 2003-03-11 | Allgon Mobile Comm Ab | Antennanordning och sätt att justera nämnda antennanordning |
| US7551562B2 (en) | 2000-12-29 | 2009-06-23 | Tropos Networks | Determining bidirectional path quality within a wireless mesh network |
| US7505426B2 (en) | 2000-12-29 | 2009-03-17 | Tropos Networks | Multi-channel mesh network |
| US6704301B2 (en) * | 2000-12-29 | 2004-03-09 | Tropos Networks, Inc. | Method and apparatus to provide a routing protocol for wireless devices |
| US6965575B2 (en) | 2000-12-29 | 2005-11-15 | Tropos Networks | Selection of routing paths based upon path quality of a wireless mesh network |
| US7065045B2 (en) | 2001-01-03 | 2006-06-20 | International Business Machines Corporation | Method and system for providing an optimal path choice for differentiated services |
| US6612188B2 (en) | 2001-01-03 | 2003-09-02 | Neptune Technology Group Inc. | Self-powered fluid meter |
| GB0100093D0 (en) | 2001-01-03 | 2001-02-14 | Vtech Communications Ltd | Adaptive frequency hopping strategy |
| US20020146985A1 (en) * | 2001-01-31 | 2002-10-10 | Axonn Corporation | Battery operated remote transceiver (BORT) system and method |
| US6784807B2 (en) | 2001-02-09 | 2004-08-31 | Statsignal Systems, Inc. | System and method for accurate reading of rotating disk |
| FR2821502A1 (fr) * | 2001-02-27 | 2002-08-30 | Thomson Csf | Procede et dispositif d'estimation d'un canal de propagation a partir de ses statistiques |
| US7266085B2 (en) | 2001-03-21 | 2007-09-04 | Stine John A | Access and routing protocol for ad hoc network using synchronous collision resolution and node state dissemination |
| US7031293B1 (en) | 2001-03-26 | 2006-04-18 | Tropos Networks, Inc. | Method and system to provide increased data throughput in a wireless multi-hop network |
| CA2818517C (en) * | 2001-03-30 | 2016-09-06 | M&Fc Holding, Llc | Enhanced wireless packet data communication system, method, and apparatus applicable to both wide area networks and local area networks |
| US6981062B2 (en) * | 2001-04-20 | 2005-12-27 | Sbc Technology Resources, Inc. | World wide web content synchronization between wireless devices |
| US7190667B2 (en) | 2001-04-26 | 2007-03-13 | Intel Corporation | Link level packet flow control mechanism |
| AR033307A1 (es) * | 2001-05-02 | 2003-12-10 | Invensys Metering Systems Nort | Modulo de lectura automatica de medidor |
| AR033319A1 (es) | 2001-05-04 | 2003-12-10 | Invensys Metering Systems Nort | Disposicion y metodo para comunicacion y control de lectura automatizada de medidores |
| US20020169643A1 (en) * | 2001-05-11 | 2002-11-14 | Statsignal Systems, Inc. | System and method for remotely processing reservations |
| US6734463B2 (en) * | 2001-05-23 | 2004-05-11 | Semiconductor Energy Laboratory Co., Ltd. | Semiconductor device comprising a window |
| US7006790B2 (en) * | 2001-05-30 | 2006-02-28 | Ericsson Inc. | Method and system for GPS bit-edge synchronization in the presence of burst-mode interference |
| US20020184391A1 (en) * | 2001-06-05 | 2002-12-05 | Motorola, Inc. | Method and system for orderly communication of chat messages in a wirless network |
| US6842460B1 (en) | 2001-06-27 | 2005-01-11 | Nokia Corporation | Ad hoc network discovery menu |
| US6961319B2 (en) | 2001-07-16 | 2005-11-01 | International Business Machines Corporation | Methods and arrangements for distribution tree development |
| US6781999B2 (en) * | 2001-07-23 | 2004-08-24 | Airvana, Inc. | Broadcasting and multicasting in wireless communication |
| WO2003012463A1 (en) * | 2001-07-27 | 2003-02-13 | Invensys Metering Systems - North America Inc. | Solid-state electricity meter |
| US7277414B2 (en) * | 2001-08-03 | 2007-10-02 | Honeywell International Inc. | Energy aware network management |
| US6671586B2 (en) * | 2001-08-15 | 2003-12-30 | Statsignal Systems, Inc. | System and method for controlling power demand over an integrated wireless network |
| US20030036810A1 (en) | 2001-08-15 | 2003-02-20 | Petite Thomas D. | System and method for controlling generation over an integrated wireless network |
| US6604751B2 (en) * | 2001-08-30 | 2003-08-12 | Fox Factory, Inc. | Inertia valve shock absorber |
| US20030213662A1 (en) * | 2001-08-30 | 2003-11-20 | Fox Robert C. | Inertia valve shock absorber |
| US7009530B2 (en) | 2001-09-13 | 2006-03-07 | M&Fc Holding, Llc | Modular wireless fixed network for wide-area metering data collection and meter module apparatus |
| US20060259607A1 (en) * | 2001-09-13 | 2006-11-16 | Network Foundation Technologies, Llc | System and method for distributing data over a computer network |
| US7536472B2 (en) * | 2001-09-13 | 2009-05-19 | Network Foundation Technologies, Llc | Systems for distributing data over a computer network and methods for arranging nodes for distribution of data over a computer network |
| DE10147164B4 (de) * | 2001-09-25 | 2004-05-06 | Siemens Ag | Verfahren zur Ermittlung der Laufzeitverzögerung einer Verbindung mit Übertragung über ein paketbasiertes Netz |
| US20030063723A1 (en) | 2001-09-28 | 2003-04-03 | Derek Booth | Interactive system for managing and remotely connecting customer utility loads |
| EP1303097A3 (en) * | 2001-10-16 | 2005-11-30 | Microsoft Corporation | Virtual distributed security system |
| US7480501B2 (en) | 2001-10-24 | 2009-01-20 | Statsignal Ipc, Llc | System and method for transmitting an emergency message over an integrated wireless network |
| US7424527B2 (en) | 2001-10-30 | 2008-09-09 | Sipco, Llc | System and method for transmitting pollution information over an integrated wireless network |
| US20030179149A1 (en) | 2001-11-26 | 2003-09-25 | Schlumberger Electricity, Inc. | Embedded antenna apparatus for utility metering applications |
| US7488313B2 (en) * | 2001-11-29 | 2009-02-10 | Boston Scientific Scimed, Inc. | Mechanical apparatus and method for dilating and delivering a therapeutic agent to a site of treatment |
| US7352715B2 (en) | 2001-11-30 | 2008-04-01 | Cellnet Innovations, Inc. | Time synchronization using dynamic thresholds |
| FR2833791B1 (fr) * | 2001-12-13 | 2004-02-06 | Telediffusion De France Tdf | Dispositif de metrologie pour la surveillance automatique d'un reseau de diffusion de signaux numeriques et reseau de diffusion comprenant un tel dispositif de metrologie |
| US6788658B1 (en) * | 2002-01-11 | 2004-09-07 | Airflow Networks | Wireless communication system architecture having split MAC layer |
| CA2369196A1 (en) | 2002-01-24 | 2003-07-24 | Alcatel Canada Inc. | System and method of downloading data for a communication switch |
| US6639957B2 (en) * | 2002-02-14 | 2003-10-28 | Itron, Inc. | Method and system for calibrating an oscillator circuit using a network based time reference |
| US7626508B2 (en) * | 2002-03-05 | 2009-12-01 | Aeromesh Corporation | Monitoring system and method |
| WO2003090411A1 (en) * | 2002-04-18 | 2003-10-30 | Sarnoff Corporation | Methods and apparatus for providing ad-hoc networked sensors and protocols |
| US6867707B1 (en) | 2002-04-24 | 2005-03-15 | Elster Electricity, Llc | Automated on-site meter registration confirmation using a portable, wireless computing device |
| US20040008683A1 (en) * | 2002-05-29 | 2004-01-15 | Cloonan Thomas J. | Method and system for improving bandwidth utilization when supporting mixes of DOCSIS 2.0 and DOCSIS 1.x cable modems |
| US7019666B2 (en) | 2002-06-10 | 2006-03-28 | Tantalus Systems Corp. | Adapter for a meter |
| US6816538B2 (en) | 2002-06-26 | 2004-11-09 | Elster Electricity, Llc | Frequency hopping spread spectrum decoder |
| US7119713B2 (en) | 2002-06-27 | 2006-10-10 | Elster Electricity, Llc | Dynamic self-configuring metering network |
| US6838867B2 (en) * | 2002-06-27 | 2005-01-04 | Elster Electricity, Llc | Electrical-energy meter |
| US20040113810A1 (en) | 2002-06-28 | 2004-06-17 | Mason Robert T. | Data collector for an automated meter reading system |
| US20040004555A1 (en) | 2002-07-03 | 2004-01-08 | Schlumbergersema Inc. | Field selectable communication network |
| US6885302B2 (en) | 2002-07-31 | 2005-04-26 | Itron Electricity Metering, Inc. | Magnetic field sensing for tamper identification |
| US7290037B2 (en) * | 2002-08-22 | 2007-10-30 | Clark Todd A | Scalable wireless remote control and monitoring system with automatic registration and automatic time synchronization |
| US8937928B2 (en) * | 2002-08-23 | 2015-01-20 | Koninklijke Philips N.V. | Frequency hopping in 5GHz WLAN via dynamic frequency selection |
| US20040040368A1 (en) * | 2002-09-04 | 2004-03-04 | Guckenberger Carl R. | Apparatus and method for quantity meter testing |
| US6763013B2 (en) | 2002-09-04 | 2004-07-13 | Harris Corporation | Intelligent communication node object beacon framework including neighbor discovery in a mobile ad hoc network |
| US20040044555A1 (en) * | 2002-09-04 | 2004-03-04 | Bangs Richard Alan | Systems, apparatus, and methods for facilitating product development |
| GB0220660D0 (en) * | 2002-09-05 | 2002-10-16 | Nokia Corp | Signal propogation delay routing |
| US6982052B2 (en) * | 2002-09-26 | 2006-01-03 | Kimberly-Clark Worldwide, Inc. | Process and apparatus for air forming an article having a plurality of superimposed fibrous layers |
| WO2004030273A1 (ja) * | 2002-09-27 | 2004-04-08 | Fujitsu Limited | データ配信方法、システム、伝送方法及びプログラム |
| US7313098B2 (en) * | 2002-09-30 | 2007-12-25 | Avaya Technology Corp. | Communication system endpoint device with integrated call synthesis capability |
| GB0224753D0 (en) * | 2002-10-24 | 2002-12-04 | Koninl Philips Electronics Nv | Beacon channel for frequency hopping wireless devices |
| US7444401B1 (en) * | 2002-11-18 | 2008-10-28 | Arkion Systems Llc | Method and apparatus for inexpensively monitoring and controlling remotely distributed appliances |
| US6996215B2 (en) * | 2002-11-27 | 2006-02-07 | Macconnell John Walter | Telemetry system and method |
| US6980091B2 (en) * | 2002-12-10 | 2005-12-27 | Current Technologies, Llc | Power line communication system and method of operating the same |
| EP1579614B1 (en) * | 2002-12-24 | 2009-04-01 | Electronics and Telecommunications Research Institute | Frequency hopping method in orthogonal frequency division multiplexing system |
| US6850197B2 (en) | 2003-01-31 | 2005-02-01 | M&Fc Holding, Llc | Printed circuit board antenna structure |
| US6859186B2 (en) | 2003-02-03 | 2005-02-22 | Silver Spring Networks, Inc. | Flush-mounted antenna and transmission system |
| US7304587B2 (en) * | 2003-02-14 | 2007-12-04 | Energy Technology Group, Inc. | Automated meter reading system, communication and control network for automated meter reading, meter data collector program product, and associated methods |
| US7068703B2 (en) * | 2003-02-18 | 2006-06-27 | Qualcomm, Incorporated | Frequency hop sequences for multi-band communication systems |
| US6931445B2 (en) | 2003-02-18 | 2005-08-16 | Statsignal Systems, Inc. | User interface for monitoring remote devices |
| US7613223B2 (en) * | 2003-02-28 | 2009-11-03 | Intel Corporation | Time-frequency coding in a multi-band ultra-wideband system |
| US7474686B2 (en) * | 2003-02-28 | 2009-01-06 | Texas Instruments Incorporated | Wireless personal area networks with rotation of frequency hopping sequences |
| WO2004086667A2 (en) * | 2003-03-24 | 2004-10-07 | Strix Systems, Inc. | Self-configuring, self-optimizing wireless local area network system |
| US7171606B2 (en) | 2003-03-25 | 2007-01-30 | Wegener Communications, Inc. | Software download control system, apparatus and method |
| US7406298B2 (en) | 2003-03-25 | 2008-07-29 | Silver Spring Networks, Inc. | Wireless communication system |
| JP2004326671A (ja) * | 2003-04-28 | 2004-11-18 | National Institute Of Advanced Industrial & Technology | 計量機器の遠隔校正システム、および、計量機器の遠隔校正方法 |
| US6940396B2 (en) | 2003-05-06 | 2005-09-06 | Distribution Control Systems, Inc. | Concurrent phase communication in TWACS |
| US7417557B2 (en) * | 2003-05-07 | 2008-08-26 | Itron, Inc. | Applications for a low cost receiver in an automatic meter reading system |
| US7649866B2 (en) | 2003-06-24 | 2010-01-19 | Tropos Networks, Inc. | Method of subnet roaming within a network |
| US7016328B2 (en) | 2003-06-24 | 2006-03-21 | Tropos Networks, Inc. | Method for allowing a client to access a wireless system |
| US7801038B2 (en) | 2003-07-14 | 2010-09-21 | Siemens Corporation | Method and apparatus for providing a delay guarantee for a wireless network |
| US7701858B2 (en) | 2003-07-17 | 2010-04-20 | Sensicast Systems | Method and apparatus for wireless communication in a mesh network |
| US7561038B2 (en) * | 2003-07-21 | 2009-07-14 | Uhs Systems Pty Limited | Telemetry system |
| US7351328B2 (en) | 2003-07-23 | 2008-04-01 | China Petroleum & Chemical Corporation | Desulfurization and novel process for same |
| US8005055B2 (en) | 2003-07-23 | 2011-08-23 | Interdigital Technology Corporation | Method and apparatus for determining and managing congestion in a wireless communications system |
| US7376087B2 (en) | 2003-08-13 | 2008-05-20 | Tropos Networks, Inc. | Method and apparatus for monitoring and displaying routing metrics of a network |
| DE10339569A1 (de) * | 2003-08-26 | 2005-04-07 | Bayer Chemicals Ag | Verfahren zur Herstellung nicht-mikroverkapselter monodisperser Perlpolymerisate |
| US7376118B2 (en) | 2003-09-05 | 2008-05-20 | Itron, Inc. | System and method for optimizing contiguous channel operation with cellular reuse |
| US7336200B2 (en) * | 2003-09-05 | 2008-02-26 | Itron, Inc. | Data communication protocol in an automatic meter reading system |
| US7099770B2 (en) | 2003-09-08 | 2006-08-29 | Axonn L.L.C. | Location monitoring and transmitting device, method, and computer program product using a simplex satellite transmitter |
| US7129900B2 (en) | 2003-09-08 | 2006-10-31 | Tantalus Systems Corp. | Meter antenna |
| WO2005034395A2 (en) * | 2003-09-17 | 2005-04-14 | Nielsen Media Research, Inc. | Methods and apparatus to operate an audience metering device with voice commands |
| US7283822B2 (en) * | 2003-10-17 | 2007-10-16 | Kineto Wireless, Inc. | Service access control interface for an unlicensed wireless communication system |
| US6836108B1 (en) | 2003-11-03 | 2004-12-28 | M & Fc Holding, Llc | Three-phase electricity meter including integral test switch |
| US20050105524A1 (en) | 2003-11-17 | 2005-05-19 | Hughes Electronics Corporation | System and method for provisioning of route information in a meshed communications network |
| CA2450984C (en) * | 2003-11-26 | 2007-02-13 | Triacta Power Technologies Inc. | Method and apparatus for monitoring power consumption on power distribution circuits for centralized analysis |
| JP4622503B2 (ja) * | 2003-12-24 | 2011-02-02 | ソニー株式会社 | 無線通信システム、無線通信装置及び無線通信方法、並びにコンピュータ・プログラム |
| US7382778B2 (en) * | 2004-01-05 | 2008-06-03 | Tropos Networks, Inc. | Link layer emulation |
| JP4101183B2 (ja) * | 2004-01-08 | 2008-06-18 | 三洋電機株式会社 | 携帯端末 |
| US7802015B2 (en) | 2004-01-26 | 2010-09-21 | Tantalus Systems Corp. | Communications system of heterogeneous elements |
| GB0402319D0 (en) | 2004-02-03 | 2004-03-10 | M & Fc Holdings Llc | Wide range power supply for polyphase electricity meter |
| US6972555B2 (en) | 2004-02-05 | 2005-12-06 | M&Fc Holding, Llc | Electronic electricity meter having configurable contacts |
| KR100617715B1 (ko) * | 2004-02-27 | 2006-08-28 | 삼성전자주식회사 | 모바일 애드 혹 네트워크에서 ｆａｔｉｍ 전송 방법 및이를 위한 매체 액세스 제어 프로토콜 계층 모듈 |
| US7756086B2 (en) * | 2004-03-03 | 2010-07-13 | Sipco, Llc | Method for communicating in dual-modes |
| US8031650B2 (en) | 2004-03-03 | 2011-10-04 | Sipco, Llc | System and method for monitoring remote devices with a dual-mode wireless communication protocol |
| US7218531B2 (en) * | 2004-04-05 | 2007-05-15 | Elster Electricity, Llc | Switching regulator with reduced conducted emissions |
| US7362737B2 (en) | 2004-04-08 | 2008-04-22 | Tropos Networks, Inc. | Minimization of channel filters within wireless access nodes |
| US7187906B2 (en) * | 2004-04-26 | 2007-03-06 | Elster Electricity, Llc | Method and system for configurable qualification and registration in a fixed network automated meter reading system |
| US7239250B2 (en) * | 2004-04-26 | 2007-07-03 | Elster Electricity, Llc | System and method for improved transmission of meter data |
| US20050251403A1 (en) | 2004-05-10 | 2005-11-10 | Elster Electricity, Llc. | Mesh AMR network interconnecting to TCP/IP wireless mesh network |
| US20050251401A1 (en) | 2004-05-10 | 2005-11-10 | Elster Electricity, Llc. | Mesh AMR network interconnecting to mesh Wi-Fi network |
| FR2871006B1 (fr) | 2004-05-28 | 2008-09-12 | Thales Sa | Procede et systeme de synchronisation distribuee |
| US7489932B2 (en) | 2004-06-03 | 2009-02-10 | Tropos Networks | Channel assignments within a mesh network |
| US7142106B2 (en) | 2004-06-15 | 2006-11-28 | Elster Electricity, Llc | System and method of visualizing network layout and performance characteristics in a wireless network |
| EP1782302A4 (en) | 2004-06-30 | 2014-08-13 | Nuri Telecom Co Ltd | REMOTE COUNTER READING SYSTEM AND METHOD WITH DUPLICATED DATA TRANSMISSION OF THE PACKET DATA TRANSMISSION AND LINE DATA TRANSMISSION |
| US7450552B2 (en) | 2004-07-02 | 2008-11-11 | Tropos Networks, Inc. | Access point control of client roaming |
| US7343255B2 (en) * | 2004-07-07 | 2008-03-11 | Itron, Inc. | Dual source real time clock synchronization system and method |
| US20060012935A1 (en) * | 2004-07-13 | 2006-01-19 | Elster Electricity, Llc | Transient protector circuit for multi-phase energized power supplies |
| US7551647B2 (en) * | 2004-07-19 | 2009-06-23 | Qvidium Technologies, Inc. | System and method for clock synchronization over packet-switched networks |
| US7460489B2 (en) | 2004-07-21 | 2008-12-02 | Tropos Networks, Inc. | Wireless mesh network timed commit provisioning |
| MX2007001704A (es) | 2004-08-12 | 2007-04-12 | Interdigital Tech Corp | Metodo y sistema para controlar el acceso a un medio de comunicacion inalambrica. |
| US7355867B2 (en) | 2004-08-17 | 2008-04-08 | Elster Electricity, Llc | Power supply for an electric meter having a high-voltage regulator that limits the voltage applied to certain components below the normal operating input voltage |
| US20060039315A1 (en) * | 2004-08-20 | 2006-02-23 | Hao Bi | Macro diversity schemes for shared dedicated control channel in broadcast multicast services |
| US20060045134A1 (en) | 2004-08-25 | 2006-03-02 | John Eldon | Ultra-wideband synchronization systems and methods |
| US7676195B2 (en) * | 2004-09-10 | 2010-03-09 | Nivis, Llc | System and method for communicating messages in a mesh network |
| US7053770B2 (en) * | 2004-09-10 | 2006-05-30 | Nivis , Llc | System and method for communicating alarm conditions in a mesh network |
| US7561598B2 (en) * | 2004-09-13 | 2009-07-14 | Agilent Technologies, Inc. | Add-on module for synchronizing operations of a plurality of devices |
| US8072945B2 (en) * | 2004-09-24 | 2011-12-06 | Aes Corporation | Link layered networks |
| US7176807B2 (en) * | 2004-09-24 | 2007-02-13 | Elster Electricity, Llc | System for automatically enforcing a demand reset in a fixed network of electricity meters |
| US7715845B2 (en) * | 2004-10-14 | 2010-05-11 | Qualcomm Incorporated | Tone hopping methods and apparatus |
| US7583202B2 (en) * | 2004-10-19 | 2009-09-01 | Echelon Corporation | Method and apparatus for an electric meter |
| US7498953B2 (en) * | 2004-11-16 | 2009-03-03 | Salser Jr Floyd Stanley | Smart transmitter for utility meters |
| US8023441B2 (en) * | 2004-12-20 | 2011-09-20 | Sensicast Systems | Method for reporting and accumulating data in a wireless communication network |
| FI118291B (fi) * | 2004-12-22 | 2007-09-14 | Timo D Haemaelaeinen | Energiatehokas langaton anturiverkko, solmulaitteita sitä varten sekä menetelmä tietoliikenteen järjestämiseksi langattomassa anturiverkossa |
| US7428229B2 (en) * | 2004-12-28 | 2008-09-23 | Motorola, Inc. | Ad hoc cluster idle node coordination |
| US20060166677A1 (en) | 2005-01-27 | 2006-07-27 | Lucent Technologies, Inc. | Balancing load of cells in inter-frequency handover of wireless communications |
| CN101160988B (zh) | 2005-02-01 | 2011-11-23 | Exs有限公司 | 用于无线接入的分层网格网络 |
| US20060171305A1 (en) * | 2005-02-03 | 2006-08-03 | Autocell Laboratories, Inc. | Access point channel forecasting for seamless station association transition |
| US20060195610A1 (en) | 2005-02-28 | 2006-08-31 | Sytex, Inc. | Security Enhanced Methods And System For IP Address Allocation |
| US20080250154A1 (en) | 2005-03-07 | 2008-10-09 | Yuanhao Sun | Self-Adaptive Multicast File Transfer Protocol |
| GB2439490B (en) | 2005-03-08 | 2008-12-17 | Radio Usa Inc E | Systems and methods for modifying power usage |
| US7664055B2 (en) * | 2005-03-21 | 2010-02-16 | Rf Monolithics, Inc. | System and method for synchronizing components in a mesh network |
| US7606169B2 (en) * | 2005-03-21 | 2009-10-20 | Rf Monolithics, Inc. | System and method for collecting routing information in a mesh network |
| US7308370B2 (en) | 2005-03-22 | 2007-12-11 | Elster Electricity Llc | Using a fixed network wireless data collection system to improve utility responsiveness to power outages |
| US20060246913A1 (en) * | 2005-04-27 | 2006-11-02 | Merboth Lawrence J | Method for handling propagation delay in a wireless communication system |
| GB2426886A (en) * | 2005-06-01 | 2006-12-06 | Agilent Technologies Inc | Measuring a delay time metric |
| US8144027B2 (en) * | 2005-07-12 | 2012-03-27 | Avaak, Inc. | Remote meter reader using a network sensor system and protocol |
| US7840178B2 (en) | 2005-07-12 | 2010-11-23 | Martin E. Hellman | FM broadcast system competitive with satellite radio |
| US7302352B2 (en) * | 2005-07-15 | 2007-11-27 | Cisco Technology, Inc. | Method and system for providing dying gasp support for a network component |
| US7558294B2 (en) * | 2005-07-27 | 2009-07-07 | Intellon Corporation | Time synchronization in a network |
| US7706822B2 (en) | 2005-08-24 | 2010-04-27 | Motorola, Inc. | Timing synchronization and beacon generation for mesh points operating in a wireless mesh network |
| US20070053309A1 (en) * | 2005-09-06 | 2007-03-08 | Texas Instruments Incorporated | Policy-Based Topology Maintenance for Wireless Networks that Employ Hybrid Tree-Based Routing with AODV |
| US20070067119A1 (en) * | 2005-09-16 | 2007-03-22 | Power Measurement Ltd. | Rack-mounted power meter having removable metering options module |
| US7142123B1 (en) | 2005-09-23 | 2006-11-28 | Lawrence Kates | Method and apparatus for detecting moisture in building materials |
| US7308369B2 (en) | 2005-09-28 | 2007-12-11 | Elster Electricity Llc | Ensuring automatic season change demand resets in a mesh type network of telemetry devices |
| US20070076740A1 (en) * | 2005-09-30 | 2007-04-05 | Arati Manjeshwar | Method and system to reduce delay and/or energy consumption in a multi-hop wireless system |
| US20070076649A1 (en) | 2005-09-30 | 2007-04-05 | Intel Corporation | Techniques for heterogeneous radio cooperation |
| US8411616B2 (en) * | 2005-11-03 | 2013-04-02 | Piccata Fund Limited Liability Company | Pre-scan for wireless channel selection |
| US7697450B2 (en) | 2005-11-30 | 2010-04-13 | Motorola, Inc. | Method and apparatus for broadcast in an ad hoc network with dynamic selection of relay nodes |
| US7593738B2 (en) * | 2005-12-29 | 2009-09-22 | Trueposition, Inc. | GPS synchronization for wireless communications stations |
| KR101397111B1 (ko) | 2006-02-14 | 2014-05-19 | 한국전자통신연구원 | 인지 무선 시스템에서의 스펙트럼 센싱 방법, 전송휴지기간배치 방법, 이를 위한 단말, 기지국 및 슈퍼프레임 구조 |
| US20090146839A1 (en) * | 2006-05-17 | 2009-06-11 | Tanla Solutions Limited | Automated meter reading system and method thereof |
| US8300653B2 (en) * | 2006-07-31 | 2012-10-30 | Harris Corporation | Systems and methods for assured communications with quality of service |
| US7808774B2 (en) | 2006-08-30 | 2010-10-05 | Boon Hou Tay | Coupling point temperature and current measuring system |
| US8024724B2 (en) * | 2006-08-31 | 2011-09-20 | Itron, Inc. | Firmware download |
| US8059009B2 (en) * | 2006-09-15 | 2011-11-15 | Itron, Inc. | Uplink routing without routing table |
| US8077693B2 (en) * | 2007-09-19 | 2011-12-13 | Samsung Electronics Co., Ltd. | Resource remapping and regrouping in a wireless communication system |
| US7961095B2 (en) | 2008-12-31 | 2011-06-14 | Gridbyte, Inc. | Method and apparatus for a cooperative alarm network |
| US8423637B2 (en) * | 2010-08-06 | 2013-04-16 | Silver Spring Networks, Inc. | System, method and program for detecting anomalous events in a utility network |
| US8396935B1 (en) | 2012-04-10 | 2013-03-12 | Google Inc. | Discovering spam merchants using product feed similarity |
-
2007
- 2007-09-10 US US11/900,200 patent/US8059009B2/en active Active
- 2007-09-10 US US11/900,203 patent/US7965758B2/en active Active
- 2007-09-10 US US11/900,198 patent/US8059011B2/en active Active
- 2007-09-10 US US11/900,202 patent/US7843834B2/en active Active
- 2007-09-10 US US11/900,199 patent/US7986718B2/en active Active
- 2007-09-11 US US11/900,411 patent/US8054821B2/en active Active
- 2007-09-11 US US11/900,398 patent/US8045537B2/en active Active
- 2007-09-11 US US11/900,414 patent/US7848362B2/en active Active
- 2007-09-12 US US11/900,658 patent/US7929916B2/en active Active
- 2007-09-12 US US11/900,625 patent/US7756030B2/en active Active
- 2007-09-13 US US11/900,906 patent/US7827268B2/en active Active
- 2007-09-13 US US11/900,903 patent/US7826398B2/en not_active Expired - Fee Related
- 2007-09-13 US US11/900,905 patent/US7764714B2/en active Active
- 2007-09-14 BR BRPI0722400-1A patent/BRPI0722400A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0722393-5A patent/BRPI0722393A2/pt not_active IP Right Cessation
- 2007-09-14 EP EP09156691.9A patent/EP2207384B1/en active Active
- 2007-09-14 EP EP20090156694 patent/EP2200372B1/en active Active
- 2007-09-14 EP EP09156673.7A patent/EP2211575B1/en active Active
- 2007-09-14 BR BRPI0722398-6A patent/BRPI0722398A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0722397-8A patent/BRPI0722397A2/pt not_active IP Right Cessation
- 2007-09-14 CA CA2941376A patent/CA2941376C/en active Active
- 2007-09-14 EP EP20090156669 patent/EP2184941B1/en active Active
- 2007-09-14 BR BRPI0716887-0A patent/BRPI0716887A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0722402-8A patent/BRPI0722402A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0722394-3A patent/BRPI0722394A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0722396-0A patent/BRPI0722396A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0722403-6A patent/BRPI0722403A2/pt not_active IP Right Cessation
- 2007-09-14 CA CA2939883A patent/CA2939883C/en active Active
- 2007-09-14 EP EP09156700.8A patent/EP2197229B1/en active Active
- 2007-09-14 CA CA2663505A patent/CA2663505C/en active Active
- 2007-09-14 CA CA2939873A patent/CA2939873C/en active Active
- 2007-09-14 AU AU2007294728A patent/AU2007294728B2/en active Active
- 2007-09-14 BR BRPI0722395-1A patent/BRPI0722395A2/pt not_active IP Right Cessation
- 2007-09-14 EP EP20090156664 patent/EP2213985B1/en active Active
- 2007-09-14 CA CA2941447A patent/CA2941447C/en active Active
- 2007-09-14 CA CA2939879A patent/CA2939879C/en active Active
- 2007-09-14 EP EP09156687.7A patent/EP2175680B1/en active Active
- 2007-09-14 BR BRPI0722401-0A patent/BRPI0722401A2/pt not_active IP Right Cessation
- 2007-09-14 EP EP20090156662 patent/EP2175675B8/en active Active
- 2007-09-14 EP EP20090156681 patent/EP2192706B1/en active Active
- 2007-09-14 EP EP07838257.9A patent/EP2059911B1/en active Active
- 2007-09-14 EP EP20090156654 patent/EP2182762B1/en active Active
- 2007-09-14 BR BRPI0722404-4A patent/BRPI0722404A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0722399-4A patent/BRPI0722399A2/pt not_active IP Right Cessation
- 2007-09-14 EP EP20090156658 patent/EP2182654B1/en active Active
- 2007-09-14 BR BRPI0722392-7A patent/BRPI0722392A2/pt not_active IP Right Cessation
- 2007-09-14 EP EP20090156659 patent/EP2184940B1/en active Active
- 2007-09-14 US US11/901,293 patent/US7756078B2/en active Active
- 2007-09-14 EP EP20090156670 patent/EP2213986B9/en not_active Expired - Fee Related
- 2007-09-14 MX MX2009002801A patent/MX2009002801A/es active IP Right Grant
- 2007-09-14 CA CA2992078A patent/CA2992078C/en active Active
- 2007-09-14 WO PCT/US2007/020022 patent/WO2008033514A2/en active Application Filing
-
2009
- 2009-06-23 AU AU2009202517A patent/AU2009202517B2/en active Active
- 2009-06-23 AU AU2009202519A patent/AU2009202519A1/en not_active Abandoned
- 2009-06-25 AU AU2009202551A patent/AU2009202551B2/en active Active
- 2009-06-25 AU AU2009202550A patent/AU2009202550B2/en active Active
- 2009-06-26 AU AU2009202589A patent/AU2009202589B2/en active Active
- 2009-06-26 AU AU2009202590A patent/AU2009202590B2/en active Active
- 2009-07-06 AU AU2009202744A patent/AU2009202744B2/en active Active
- 2009-07-06 AU AU2009202736A patent/AU2009202736B2/en active Active
- 2009-07-06 AU AU2009202732A patent/AU2009202732B2/en not_active Ceased
- 2009-07-06 AU AU2009202748A patent/AU2009202748B2/en active Active
- 2009-07-06 AU AU2009202738A patent/AU2009202738B2/en active Active
- 2009-07-06 AU AU2009202735A patent/AU2009202735B2/en active Active
- 2009-07-06 AU AU2009202733A patent/AU2009202733B2/en not_active Ceased
-
2010
- 2010-07-08 US US12/832,173 patent/US8488482B2/en active Active
- 2010-08-02 US US12/848,502 patent/US9129514B2/en active Active
- 2010-08-17 US US12/857,901 patent/US8462015B2/en active Active
- 2010-10-12 US US12/902,853 patent/US8391177B2/en active Active
-
2011
- 2011-04-11 US US13/084,113 patent/US8270910B2/en active Active
- 2011-04-18 US US13/088,702 patent/US20110193719A1/en not_active Abandoned
- 2011-05-03 US US13/099,774 patent/US8437378B2/en active Active
- 2011-05-31 AU AU2011202556A patent/AU2011202556B2/en active Active
- 2011-09-19 US US13/236,251 patent/US8442029B2/en active Active
- 2011-11-07 US US13/290,806 patent/US8441987B2/en active Active
- 2011-11-14 US US13/295,435 patent/US20120119923A1/en not_active Abandoned
- 2011-11-14 US US13/295,413 patent/US8907812B2/en active Active
-
2013
- 2013-02-28 US US13/780,001 patent/US8848571B2/en active Active
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0722400A2 (pt) | protocolo de lan de rf de medição e utilização e gerenciamento de célula/nó |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B03A | Publication of a patent application or of a certificate of addition of invention [chapter 3.1 patent gazette] | ||
| B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] |
Free format text: REFERENTE A 9A E 10AANUIDADES |
|
| B08K | Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette] |