BRPI0716887A2 - protocolo de lan de rf de mediÇço e utilizaÇço e gerencimento de cÉlula/nà - Google Patents
protocolo de lan de rf de mediÇço e utilizaÇço e gerencimento de cÉlula/nà Download PDFInfo
- Publication number
- BRPI0716887A2 BRPI0716887A2 BRPI0716887-0A BRPI0716887A BRPI0716887A2 BR PI0716887 A2 BRPI0716887 A2 BR PI0716887A2 BR PI0716887 A BRPI0716887 A BR PI0716887A BR PI0716887 A2 BRPI0716887 A2 BR PI0716887A2
- Authority
- BR
- Brazil
- Prior art keywords
- sequence
- cell
- jump
- network
- node
- Prior art date
Links
- 238000005259 measurement Methods 0.000 title claims abstract description 50
- 238000000034 method Methods 0.000 claims description 230
- 230000006854 communication Effects 0.000 claims description 207
- 238000004891 communication Methods 0.000 claims description 207
- 230000001360 synchronised effect Effects 0.000 claims description 86
- 238000009434 installation Methods 0.000 claims description 22
- 238000013467 fragmentation Methods 0.000 claims description 8
- 238000006062 fragmentation reaction Methods 0.000 claims description 8
- 238000010276 construction Methods 0.000 claims 2
- 230000015572 biosynthetic process Effects 0.000 claims 1
- 150000003839 salts Chemical class 0.000 claims 1
- 239000013078 crystal Substances 0.000 abstract description 40
- 230000007246 mechanism Effects 0.000 abstract description 23
- 238000005516 engineering process Methods 0.000 abstract description 18
- 230000005611 electricity Effects 0.000 abstract description 16
- 238000009826 distribution Methods 0.000 abstract description 13
- 238000002955 isolation Methods 0.000 abstract description 11
- 230000003044 adaptive effect Effects 0.000 abstract description 10
- 230000007613 environmental effect Effects 0.000 abstract description 10
- 238000005457 optimization Methods 0.000 abstract description 6
- 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
- 101000821257 Homo sapiens Syncoilin Proteins 0.000 description 163
- 102100021919 Syncoilin Human genes 0.000 description 163
- 108091006146 Channels Proteins 0.000 description 156
- 230000005540 biological transmission Effects 0.000 description 121
- 230000008569 process Effects 0.000 description 109
- 239000003795 chemical substances by application Substances 0.000 description 49
- 230000004044 response Effects 0.000 description 47
- 238000007726 management method Methods 0.000 description 46
- 238000004422 calculation algorithm Methods 0.000 description 42
- 230000006870 function Effects 0.000 description 41
- 238000012546 transfer Methods 0.000 description 40
- 230000000875 corresponding effect Effects 0.000 description 32
- 238000012937 correction Methods 0.000 description 30
- 238000009792 diffusion process Methods 0.000 description 27
- 230000008859 change Effects 0.000 description 26
- 238000013459 approach Methods 0.000 description 23
- 238000012790 confirmation Methods 0.000 description 21
- 238000012544 monitoring process Methods 0.000 description 21
- 238000005311 autocorrelation function Methods 0.000 description 19
- 238000004458 analytical method Methods 0.000 description 18
- 230000033228 biological regulation Effects 0.000 description 18
- 230000008901 benefit Effects 0.000 description 15
- 239000000872 buffer Substances 0.000 description 14
- 238000004364 calculation method Methods 0.000 description 14
- 238000000605 extraction Methods 0.000 description 14
- 238000001514 detection method Methods 0.000 description 12
- 230000004913 activation Effects 0.000 description 11
- 238000007792 addition Methods 0.000 description 11
- 230000009471 action Effects 0.000 description 10
- 230000007175 bidirectional communication Effects 0.000 description 10
- 230000007423 decrease Effects 0.000 description 10
- 238000003860 storage Methods 0.000 description 10
- 235000008694 Humulus lupulus Nutrition 0.000 description 9
- 238000010586 diagram Methods 0.000 description 9
- 230000001965 increasing effect Effects 0.000 description 9
- 238000001228 spectrum Methods 0.000 description 9
- 238000013475 authorization Methods 0.000 description 8
- 230000001934 delay Effects 0.000 description 8
- 230000000694 effects Effects 0.000 description 8
- 230000001976 improved effect Effects 0.000 description 8
- 230000000737 periodic effect Effects 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 239000012896 selective serotonin reuptake inhibitor Substances 0.000 description 8
- 229940124834 selective serotonin reuptake inhibitor Drugs 0.000 description 8
- 230000001276 controlling effect Effects 0.000 description 6
- 230000003111 delayed effect Effects 0.000 description 6
- 238000003891 environmental analysis Methods 0.000 description 6
- 230000036039 immunity Effects 0.000 description 6
- 239000000523 sample Substances 0.000 description 6
- 208000011580 syndromic disease Diseases 0.000 description 6
- 125000004122 cyclic group Chemical group 0.000 description 5
- 238000013075 data extraction Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 230000003612 virological effect Effects 0.000 description 5
- 230000006399 behavior Effects 0.000 description 4
- 238000006243 chemical reaction Methods 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
- 230000010354 integration Effects 0.000 description 4
- 238000011084 recovery Methods 0.000 description 4
- 230000001105 regulatory effect Effects 0.000 description 4
- 239000000758 substrate Substances 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 4
- 238000011144 upstream manufacturing Methods 0.000 description 4
- 238000012935 Averaging Methods 0.000 description 3
- 101100508818 Mus musculus Inpp5k gene Proteins 0.000 description 3
- 206010033799 Paralysis Diseases 0.000 description 3
- 101100366438 Rattus norvegicus Sphkap gene Proteins 0.000 description 3
- 230000001133 acceleration Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 3
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 239000012634 fragment Substances 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 238000012423 maintenance Methods 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
- 101100518501 Mus musculus Spp1 gene Proteins 0.000 description 2
- 230000032683 aging 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
- 238000005314 correlation function Methods 0.000 description 2
- 238000013016 damping Methods 0.000 description 2
- 238000013523 data management Methods 0.000 description 2
- 238000000354 decomposition reaction Methods 0.000 description 2
- 238000009795 derivation Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 238000006073 displacement reaction Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 150000002500 ions Chemical class 0.000 description 2
- 238000005304 joining 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
- 230000000717 retained effect Effects 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- 230000000630 rising effect Effects 0.000 description 2
- 230000007480 spreading Effects 0.000 description 2
- 238000003892 spreading Methods 0.000 description 2
- 238000007619 statistical method Methods 0.000 description 2
- 238000006467 substitution reaction 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
- 101100043727 Caenorhabditis elegans syx-2 gene Proteins 0.000 description 1
- 101100068089 Danio rerio gcna gene Proteins 0.000 description 1
- 108700026140 MAC combination Proteins 0.000 description 1
- 241001181114 Neta Species 0.000 description 1
- 101000606406 Nicotiana tabacum Pistil-specific extensin-like protein Proteins 0.000 description 1
- ATJFFYVFTNAWJD-UHFFFAOYSA-N Tin Chemical compound [Sn] ATJFFYVFTNAWJD-UHFFFAOYSA-N 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
- 150000001447 alkali salts Chemical group 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 239000011230 binding agent Substances 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000015556 catabolic process Effects 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
- 230000006378 damage Effects 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000013499 data model Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 230000008021 deposition Effects 0.000 description 1
- 238000003745 diagnosis 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
- 238000011156 evaluation Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000009432 framing Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000009191 jumping Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 238000011068 loading method Methods 0.000 description 1
- 235000013372 meat Nutrition 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 239000011022 opal Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 244000045947 parasite Species 0.000 description 1
- 230000007170 pathology Effects 0.000 description 1
- 230000037361 pathway Effects 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000001902 propagating effect Effects 0.000 description 1
- 230000000306 recurrent effect Effects 0.000 description 1
- 230000008929 regeneration Effects 0.000 description 1
- 238000011069 regeneration method Methods 0.000 description 1
- 238000004353 relayed correlation spectroscopy Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 210000004722 stifle Anatomy 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000001629 suppression Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012549 training 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 having no potential barriers, 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Quality & Reliability (AREA)
- Electromagnetism (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Radio Relay Systems (AREA)
- Telephonic Communication Services (AREA)
- Position Fixing By Use Of Radio Waves (AREA)
Abstract
PROTOCOLO DE LAN DE RF DE MEDIÇçO E UTILIZAÇçO E GERENCIAMENTO DE CÉLULA / Nà. 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 de freqüê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 para evitaçã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ÇÃO EGERENCIAMENTO DE CÉLULA / NÕ
REIVINDICAÇÕES DE PRIORIDADE
Este pedido reivindica o beneficio do Pedido dePatente U.S. previamente depositado intitulado "METERING RFLAN PROTOCOL AND CELL/NODE UTILIZATION AND MANAGEMENT",USSN respectivamente atribuído 60/845.056, conformedepositado em 15 de setembro de 2006, e USSN atribuído60/845.994, conforme depositado em 20 de setembro de 2006,os quais são incorporados aqui como referência em suastotalidades para todas as finalidades.
CAMPO DA INVENÇÃO
A presente tecnologia se refere a protocolos paramedidores de serviço de utilidade pública associados a umaestrutura operacional aberta. Mais particularmente, opresente assunto se refere a um assunto de protocolo parauma infra-estrutura de medição avançada, adaptável a váriospadrões internacionais, enquanto suporta economicamente umasolução de rede de malha de 2 vias em um ambiente sem fio,tal como para operação em um campo de medidor deeletricidade residencial.
ANTECEDENTES DA INVENÇÃO
O objetivo geral da metrologia é monitorar um ou maisfenômenos físicos selecionados para se permitir um registrode eventos monitorados. Essa finalidade básica^ demetrologia pode ser aplicada a uma variedade dedispositivos de medição usados em vários contextos. Umaárea ampla de medição se refere, por exemplo, a medidoresde serviço de utilidade pública. Esse papel^ pode incluir,especificamente, nesse contexto, a monitoração do consumoou da produção de uma variedade de formas de energia ououtros bens de consumo, por exemplo, incluindo, mas nãolimitando, eletricidade, água, gás ou óleo.
Mais particularmente, concernindo a medidores deeletricidade, as formas mecânicas de registradores têm sidousadas historicamente para a extração de dados de consumoacumulado de eletricidade. Uma abordagem como essa proviaum dispositivo de campo relativamente confiável,especialmente para a tarefa básica ou de nívelrelativamente mais baixo de simplesmente monitorar oconsumo acumulado em quilowatt-hora.
A forma mecânica básica precedente de registradortipicamente era limitada no seu modo de saída, de modo queapenas uma função de metrologia muito básica ou de nívelmais baixo era obtida. Subseqüentemente, formas eletrônicasde dispositivos de metrologia começaram a ser introduzidas,para se permitirem níveis relativamente mais altos demonitoração, envolvendo formas e modos de dados diferentes.
No contexto de medidores de eletricidadeespecificamente, para uma variedade de finalidades degerenciamento e de tributação, tornou-se desejável obterdados de uso além das leituras básicas de consumo dequilowatt-hora disponíveis com muitos medidores deeletricidade. Por exemplo, dados desejados adicionaisincluíam a taxa de consumo de eletricidade, ou a data e ahora de consumo (os assim denominados dados de "tempo deuso"). Dispositivos de estado sólido providos em placas decircuito impresso, por exemplo, utilizando componentes decircuito integrado programáveis, proveram ferramentasefetivas para a implementação de muitas dessas funções demonitoração de nível mais alto desejadas no contexto demedidor de eletricidade.
Além da introdução benéfica de formas eletrônicas demetrologia, uma variedade de registradores eletrônicos foiintroduzida com certas vantagens. Mais ainda, outras formasde saída de dados foram introduzidas e são benéficas paracertas aplicações, incluindo transmissões com fio, umasaída de dados através de transmissão por freqüência derádio, saída em pulso de dados, e via de conexão por linhatelefônica, tais como modems ou enlaces celulares.
O advento dessa variedade e de alternativasfreqüentemente requereu que as companhias de serviço deutilidade pública fizessem escolhas quanto a quaistecnologias utilizar. Essas escolhas de tempos em temposeram feitas com base em pontos filosóficos e preferênciase/ou com base em pontos práticos, tais como treinamento efamiliaridade do pessoal de campo com projetos específicos.
Um outro aspecto do progresso da tecnologia nessa áreade metrologia é que vários arranjos de retroajuste foraminstituídos. Por exemplo, algumas tentativas foram feitaspara a provisão de dispositivos de medição com recursosmais avançados selecionados, sem se ter que mudarcompletamente ou substituir o medidor básico no campo. Porexemplo, foram feitas tentativas de equipar um dispositivode medição basicamente mecânico com uma saída eletrônica dedados, tal como para facilitar ligações de telemetria porrádio.
Um outro aspecto da indústria de medidor deeletricidade é que as companhias de serviço de utilidadepública têm exigências de larga escala, às vezes envolvendoliteralmente centenas de milhares de instalações de medidorindividuais, ou pontos de dados. A implementação demudanças em incrementos na tecnologia, tal como umretroajuste de novos recursos em um equipamento existente,ou uma tentativa de implementação de mudanças emcomponentes básicos os quais tornam vários componentes nãointercambiáveis com outras configurações já no campo podegerar problemas consideráveis na indústria.
Os medidores de eletricidade tipicamente incluem umcircuito de entrada para o recebimento de sinais devoltagem e de corrente no serviço elétrico. Um circuito deentrada de qualquer tipo ou projeto especifico para orecebimento dos sinais de corrente de serviço elétrico éreferido aqui geralmente como um circuito de aquisição decorrente, enquanto um circuito de qualquer tipo ou projetopara o recebimento dos sinais de voltagem de serviçoelétrico é referido aqui geralmente como um circuito deaquisição de voltagem.
Um circuito de entrada de medidor de eletricidade podeser provido com capacidades de monitoração de uma ou maisfases, dependendo de a monitoração ser para ser provida emum ambiente mono ou multifásico. Mais ainda, é desejávelque um circuito configurável seletivamente possa serprovido, de modo a se permitir a provisão de serviçosnovos, alternativos ou atualizados ou o processamento decapacidades em um dispositivo de medição existente. Essasvariações nos ambientes ou nas capacidades de monitoraçãodesejados, contudo, levam à exigência que váriasconfigurações de metrologia diferentes sejam divisadas paraa acomodação do número de fases requeridas ou desejadas aserem monitoradas ou para a provisão de uma capacidade deprocessamento alternativa, adicional ou atualizada em ummedidor de serviço de utilidade pública.
Mais recentemente, um novo protocolo da ANSI, o ANSIC12.22 está sendo desenvolvido, que pode ser usado para sepermitir a abertura de comunicações de protocolo dentredispositivos de metrologia a partir de vários fabricantes.C12.22 é a designação da última subclasse da família C12.xxda ANSI de normas de Comunicação e Dados de Medidorpresentemente sob desenvolvimento. As normas presentementedefinidas incluem a ANSI C12.18 relativa a especificaçõesde protocolo para portas óticas do Tipo 2; a ANSI C12.19relativa a definições de Tabela de Dados de Medidor daIndústria de Serviço de Utilidade Pública; e a ANSI C12.21relativa a um transporte de Serviço de Telefonia AntigoSimples (POTS) de definição de Tabelas de Dados de C12.19.Deve ser apreciado que, embora o restante da discussãopossa descrever o C12.22 como um protocolo padrão, pelomenos no momento do depósito do presente pedido, esseprotocolo ainda está sendo desenvolvido, de modo que apresente exposição na realidade é pretendida para adescrição de um protocolo aberto, que pode ser usado comoum protocolo de comunicações para uma metrologia em rede eé referido para fins de discussão como a norma C12.22 ou oprotocolo C12.22.
O C12.22 é um protocolo de camada de aplicativo queprovê o transporte de tabelas de dados de C12.19 porqualquer meio de rede. Os padrões atuais para o protocoloC12.22 incluem: recursos de autenticação e de encriptação;metodologia de endereçamento provendo identificadoresúnicos para entidades corporativas, de comunicação e dedispositivo final; modelos de dados de autodescrição; eroteamento de mensagem por redes heterogêneas.
Muito como um protocolo HTTP provê uma camada deaplicativo comum para navegadores da web, o C12.22 provêuma camada de aplicativo comum para dispositivos demedição. Os benefícios do uso de um padrão como esseincluem a provisão de: uma metodologia para comunicações·desessão e sem sessão; encriptação de dados comuns esegurança; um mecanismo de endereçamento comum para uso pormeios de rede proprietários e não proprietários;interoperabilidade dentre dispositivos de medição em umambiente de comunicação comum; uma integração do sistemacom dispositivos de terceiros através de interfaces comunse abstração de gateway; comunicações de 2 vias e de 1 viacom dispositivos finais; e segurança melhorada,confiabilidade e velocidade para a transferência de dadosde medição por redes heterogêneas.
Para entendimento da razão pela qual os serviços deutilidade pública estão intensamente interessados emcomunicações de protocolo aberto, considere o processo e afacilidade de envio de e-mails a partir de um computadorlaptop ou de um smartphone. Os provedores de Internetdependem do uso de protocolos abertos para a provisão de umserviço de e-mail. Os e-mails são enviados e recebidosdesde que os endereços de e-mail sejam válidos, as caixasde correio não estejam cheias, e os percursos decomunicação estejam funcionais. A maioria dos usuários dee-mail tem a opção de escolher dentre vários provedores deInternet e várias tecnologias, de discada a celular a debanda larga, dependendo principalmente do custo, davelocidade e da mobilidade. Os endereços de e-mail estão emum formato comum, e os protocolos pedem que o e-mail sejaportado por portadoras de comunicação sem mudança do e-mail. O protocolo aberto apresentado na norma da ANSIC12.22 prove a mesma oportunidade para comunicações demedidor por redes.
Além disso, o desejo de capacidades de processamentoaumentadas, bem como outras considerações, incluindo, masnão limitando, um desejo de prover capacidades melhoradaspara componentes de metrologia individuais em uma estruturaoperacional aberta, leva a exigências para a criação de umainterface de tais componentes com aplicativos de sistema.
Como tal, é desejado prover um protocolo melhoradopara aplicações de infra-estrutura de medição avançada emuma estrutura operacional aberta.
Embora vários aspectos e modalidades alternativaspossam ser conhecidos no campo de medição de serviço deutilidade pública, nenhum projeto emergiu que geralmenteenvolva as características referenciadas acima e outrosrecursos desejáveis associados à tecnologia de medição deserviço de utilidade pública, conforme apresentado aqui.
SUMÁRIO DA INVENÇÃO
Tendo em vista os recursos reconhecidos encontrados natécnica anterior e endereçados pelo presente assunto, umaparelho melhorado e uma metodologia permitindo uma infra-estrutura de medição avançada em uma estrutura operacionalaberta foram providos.
Em um arranjo de exemplo, uma metodologia e o aparelhocorrespondente foram providos para se permitir umatransmissão de uma informação entre um medidor de serviçode utilidade pública e um aplicativo operacional através deuma rede de salto de freqüência operada de acordo com opresente assunto de protocolo.
Em uma de suas formas mais simples, a presentetecnologia prove uma rede e protocolos de medidormelhorados.
Um aspecto positivo do presente assunto é que elesuporta medidores em um sistema C12.22 / C12.19 do padrãoANSI, enquanto se suporta economicamente uma solução derede de malha de 2 vias em um ambiente sem fio, tal comopara operação em um campo de medidor de eletricidaderesidencial, tudo para se permitir uma inserção adaptativabaseada em célula de medidores de C12.22 em uma estruturaaberta.
Um outro aspecto positivo do presente assunto é queele prove um isolamento de célula através de seqüênciasquase ortogonais em uma rede de salto de freqüência. Algunsaspectos positivos adicionais se referem a uma rede operadacom o presente assunto de protocolo é relacionada adistribuição e recuperação de relógio de tempo real, sinalde transmissão de roteamento sem requerer uma tabela deroteamento, e manuseando bit "Beacon Requests" e"Registered State" que resolvem para evitar as rotascirculares.
Ainda aspectos positivos adicionais do presenteassunto relata a utilização ou gerenciamento de célula ounó uma rede de malha se referem ao gerenciamento de tamanhode célula, para gerenciamento de número de filhos, paracompensação de deriva de cristal em uma rede de malha, paradifusão de recursos de reconhecimento, e para controle decarga de tráfego em uma rede de malha.
Aspectos adicionais do presente assunto se referemrecursos de ferramenta de avaliação ambiental de RFembutido para calibração da necessidade de performance detransceptores de RF, mecanismos de roteamento de enlacedescendente, recursos de sistema de notificação de falha, ouso de um percurso de atraso de propagação mínimo para aotimização de uma rede de malha, e operação no nível de nóde uma fase de descoberta em uma rede de salto defreqüência.
O presente assunto igualmente se refere a umametodologia, bem como ao assunto de aparelho relacionado,no nível de rede e no nível de dispositivo. Uma modalidadede método de exemplo presente se refere a uma metodologiapara a geração de uma seqüência pseudo-randômica para usoem uma rede de salto de freqüência de sistema de mediçãoavançado, compreendendo: o estabelecimento de uma redeincluindo uma instalação central e uma pluralidade dedispositivos finais, pelo menos alguns desses dispositivosfinais compreendendo dispositivo de metrologia, e onde cadadispositivo final está associado a uma de uma pluralidadede células, a cada célula sendo atribuído um identificadorde célula único; a construção de uma seqüência de saltoexterna para uma dada célula usando-se o identificador decélula único da dada célula como uma semente; o uso doselementos da seqüência de salto externa para a seleção deuma seqüência de salto interna de N saltos, onde o inteiroN é o número de canais usados pela rede de salto defreqüência de sistema de medição avançado; e a aplicação daseqüência selecionada como um padrão de salto detransceptor para um dispositivo final selecionado na dadacélula.
Uma presente modalidade de aparelho de exemplo serefere a uma rede de salto de freqüência de sistema demedição avançado que compreende: uma instalação central; euma pluralidade de dispositivos finais, pelo menos algunsdesses dispositivos finais compreendendo dispositivo demetrologia, com a referida instalação central e a referidapluralidade de dispositivos finais sendo configurada paracomunicações bidirecionais entre eles, e com cadadispositivo final estando associado a uma de umapluralidade de células, cada uma tendo um identificador decélula único. Preferencialmente, nessa modalidade deexemplo, cada dispositivo final em uma dada célula éconfigurado para comunicações sincronizadas com cada outrodispositivo final na dada célula. Com um arranjo como esse,vantajosamente as comunicações dentre células adjacentessão substancialmente isoladas; e as comunicações efetuadaspor um ou mais dispositivos finais em uma dada célula sãoefetuadas usando-se um padrão de salto formado a partir deuma combinação alojada de duas seqüências, incluindo umaseqüência interna gerada com aritmética de campo de Galoise uma seqüência externa gerada usando-se o identificador decélula único para a dada célula como uma semente.
Uma outra modalidade de exemplo presente do presenteassunto, mais particularmente relativa ao assunto dedispositivo, refere-se a um dispositivo de metrologia parauso com uma rede de salto de freqüência de sistema demedição avançado, esse dispositivo de metrologiacaracterizado por um identificador único.
Preferencialmente, esse dispositivo de metrologia deexemplo pode compreender uma porção de metrologiaconfigurada para a medição do consumo de um bem de consumode serviço de utilidade pública; uma porção de transmissorconfigurada para a transmissão de uma informação deconsumo; e uma porção de receptor configurada para arecepção de uma informação a partir de outros dispositivosde rede. Com esse dispositivo de exemplo, preferencialmentea porção de transmissor e a porção de receptor sãoconfiguradas para comunicação usando um padrão de salto defreqüência formado a partir de uma combinação alojada deduas seqüências, incluindo uma seqüência de salto internagerada com aritmética de campo de Galois e uma seqüência desalto externa gerada usando-se o identificador único para odispositivo de metrologia como uma semente.
Uma modalidade de exemplo presente se refere a ummétodo para a provisão de uma distribuição de relógio emtempo real em uma rede de malha de sistema de mediçãoavançado. Uma modalidade de exemplo como essapreferencialmente pode compreender o estabelecimento de umarede que inclui pelo menos um nó de raiz e uma pluralidadede dispositivos de nó, pelo menos alguns dessesdispositivos de nó compreendendo dispositivos demetrologia; a configuração da rede para comunicaçõesbidirecionais entre pelo menos um nó de raiz e cada um dapluralidade de dispositivos de nó; o estabelecimento de umhiperquadro tendo um comprimento predeterminado; divisão dohiperquadro em um número predeterminado de intervalos detempo representado por números de intervalo de tempovariando de zero ao número predeterminado de intervalos detempo; o estabelecimento de um número de hiperquadro máximocorrespondente ao número de vezes que o hiperquadro é paraser repetido em uma seqüência representada pelos números dehiperquadro variando de zero a esse número de hiperquadromáximo; a configuração de pelo menos um nó de raiz paracomunicações com um padrão de tempo predeterminado; oincremento repetidamente do número de intervalo de tempo,de modo que o número de intervalo de tempo role passandopelo zero como o próximo número seguindo-se ao númeropredeterminado de intervalos de tempo; o incremento donúmero de hiperquadro uma vez seguindo-se a cada rolagem donúmero de intervalo de tempo, de modo que o número dehiperquadro role passando pelo zero como o próximo númeroseguindo-se ao número máximo de hiperquadros; e a difusãode uma mensagem incluindo uma estampa de tempo derivada dopadrão de tempo predeterminado a partir do nó de raiz até apluralidade de dispositivos de nó sempre que o número dehiperquadro e o número de intervalo de tempo forem ambosnulos. Com essa metodologia de exemplo, a pluralidade dedispositivos de nó pode ser sincronizada, cada um, com o nóde raiz.
Uma outra modalidade de metodologia de exemplopresente pode se relacionar a um método para aressincronização de uma informação de relógio em tempo realde uma rede de malha de sistema de medição avançado. Essametodologia preferencialmente pode compreender oestabelecimento de uma rede incluindo pelo menos um nó deraiz e uma pluralidade de dispositivos de nó, pelo menosalguns desses dispositivos de nó compreendendo dispositivosde metrologia; a configuração da rede para comunicaçõesbidirecionais entre pelo menos um nó de raiz e cada um dapluralidade de dispositivos de nó; a configuração dapluralidade de dispositivos de nó de modo que um ou maisdispositivos de nó correspondam a um ou mais dispositivosde nó filho e um ou mais dispositivos de nó correspondam adispositivos de nó pai; a associação de cada dispositivo denó filho a um ou mais dispositivos de nó pai; a transmissãode uma informação de tempo de atualização para cadadispositivo de nó filho a partir de seus um ou maisdispositivos de nó pai associados em um formato de pacoteincluindo porções predeterminadas de preâmbulo e decabeçalho em uma taxa de bit predeterminada; e aconfiguração de cada dispositivo de nó filho para aressincronização de si mesmo com base na informação detempo de atualização transmitida a cada vez que ele receberuma mensagem a partir de um de seus dispositivos de nó paiassociados.
Uma outra presente modalidade de exemplo maisparticularmente relativa ao presente aparelho ser refere auma rede de malha de sistema de medição avançado,preferencialmente compreendendo um nó de raiz; e umapluralidade de dispositivos de nó. Ainda, cada um dessesdispositivos de nó preferencialmente é configurado paracomunicações baseadas bidirecionais com o nó de raiz, e compelo menos alguns desses dispositivos de nó compreendendodispositivos de metrologia. Mais ainda, preferencialmentecada um dessa pluralidade de dispositivos de nó éadicionalmente configurado para a transmissão derespectivas mensagens de pacote, cada mensagem de pacotecontendo pelo menos uma porção de preâmbulo e uma porção decabeçalho. Com o arranjo de exemplo precedente, cada umdessa pluralidade de dispositivos de nó é adicionalmenteconfigurado para operar de acordo com os intervalos detempo de repetição em hiperquadros de repetição, com cadaum dessa pluralidade de dispositivos de nó atribuído umendereço de célula de rede e um número de nível com base nonúmero de saltos de cada respectivo dispositivo de nó apartir do referido nó de raiz, e com cada mensagem depacote incluindo pelo menos uma indicação do número denível de dispositivo de nó de transmissão, endereço decélula e intervalo de tempo. Com a prática de umamodalidade de exemplo como essa, a sincronização de todosos dispositivos de nó na rede pode ser mantida.
Um método de exemplo presente se refere a umametodologia para uma rede de malha de sistema de mediçãoavançado com comunicações de enlace ascendente de auto-otimização. Essa metodologia de exemplo presente podecompreender o estabelecimento de uma rede incluindo umainstalação central e uma pluralidade de dispositivosfinais, pelo menos alguns desses dispositivos finaiscompreendendo dispositivos de metrologia, e pelo menosalguns desses dispositivos finais compreendem relês decélula os quais provêem comunicações entre outros dosdispositivos finais e a instalação central; a configuraçãoda rede para comunicações bidirecionais entre a instalaçãocentral e cada um da pluralidade de dispositivos finaisatravés de associações com respectivos relês de célula; acomputação de um atraso de propagação local médio para cadaenlace de um salto para comunicações de enlace ascendente apartir de dispositivos finais em direção a seu relê decélula; a computação do atraso de propagação médio globalao longo de cada percurso de enlace ascendente a partir deum dispositivo final para seu relê de célula associado; aseleção em cada dispositivo final do valor mais baixo deatraso de propagação médio global para a definição de seupróprio valor de atraso de propagação global otimizado; e acondução de comunicações de enlace ascendente usando opercurso correspondente ao valor selecionado. Com essametodologia de exemplo, as comunicações de enlaceascendente a partir dos dispositivos finais com ainstalação central são otimizadas sem se requerer umarmazenamento de uma tabela de roteamento.
Uma modalidade de aparelho de exemplo presente serefere a uma rede de malha de sistema de medição avançadocom comunicações de enlace ascendente de auto-otimização.Essa modalidade de exemplo preferencialmente compreende umainstalação central; e uma pluralidade de dispositivosfinais. Ainda, pelo menos alguns desses dispositivos finaispreferencialmente compreendem dispositivos de metrologia,enquanto pelo menos alguns desses dispositivos finaiscompreendem relês de célula os quais provêem comunicaçõesentre outros dos dispositivos finais e a instalaçãocentral. Mais ainda, cada dispositivo finalpreferencialmente é configurado para comunicaçõesbidirecionais com a instalação central através de um relêassociado desses relês de célula. Por essa modalidade deexemplo, preferencialmente, cada dispositivo final éconfigurado para computação de um atraso de propagaçãolocal médio para cada enlace de um salto para comunicaçõesde enlace ascendente a partir de si mesmo em direção ao seurelê de célula associado, para computação do atraso depropagação médio global ao longo de cada percurso de enlaceascendente a partir de si mesmo até seu relê de célulaassociado, para a seletivamente para si mesmo do valor maisbaixo de atraso de propagação médio global para a definiçãode seu próprio valor de atraso de propagação globalotimizado e para condução de comunicações de enlaceascendente usando o percurso correspondente ao valorselecionado. Com uma modalidade como essa, as comunicaçõesde enlace ascendente a partir desses dispositivos finaispara a instalação central são otimizadas, sem se requerer oarmazenamento de uma tabela de roteamento.
Ainda uma outra modalidade de exemplo presente serefere a um dispositivo de metrologia para uso com uma redede malha de sistema de medição avançado com comunicações deenlace ascendente de auto-otimização, e incluindo umainstalação central, uma pluralidade de dispositivos finais,com pelo menos alguns desses dispositivos finaiscompreendendo esses dispositivos de metrologia, e pelomenos alguns desses dispositivos finais compreendendo relêsde célula os quais provêem comunicações entre outros dessesdispositivos finais e a instalação central, com cadadispositivo final configurado para comunicaçõesbidirecionais com essa instalação central através de umrelê associado desses relês de célula. Esse dispositivo demetrologia de exemplo presente preferencialmente podecompreender uma porção de metrologia configurada para amedição do consumo de um bem de consumo de serviço deutilidade pública; uma porção de transmissor configuradapara a transmissão de uma informação de consumo e outrosdados; e uma porção de receptor configurada para receberuma 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 dereceptor são configuradas para a computação de um atraso depropagação local médio para cada enlace de um salto paracomunicações de enlace ascendente a partir dessedispositivo de metrologia em direção a seu relê de célulaassociado, para computação do atraso de propagação médioglobal ao longo de cada percurso de enlace ascendente apartir desse dispositivo de metrologia até seu relê decélula associado, para seleção para si mesmo do valor maisbaixo de atraso de propagação médio global para a definiçãode seu próprio valor de atraso de propagação globalotimizado, e para a condução de comunicações de enlaceascendente usando o percurso correspondente ao valorselecionado. Com essa modalidade de exemplo, ascomunicações de enlace ascendente a partir dessedispositivo de metrologia para uma instalação central deuma rede de malha de sistema de medição avançado associadasão otimizadas, sem se requerer um armazenamento de umatabela de roteamento de enlace ascendente nesse dispositivode metrologia.
Uma presente modalidade de exemplo concerne a umametodologia para um dispositivo final em uma rede de saltode freqüência de sistema de medição avançado paramanipulação de uma requisição de sincronização de um outrodispositivo final. Essa presente modalidade de exemplo serefere à provisão de uma rede de salto de freqüênciaincluindo uma pluralidade de dispositivos finais, pelomenos alguns desses dispositivos finais compreendendodispositivos de metrologia; a configuração da pluralidadede dispositivos finais para comunicações bidirecionais comoutros dispositivos finais; o recebimento de uma requisiçãode sincronização em um dado dispositivo final a partir deum dispositivo final não sincronizado vizinho; e determinarse o dado dispositivo final recebeu em um númeropredeterminado de intervalos de tempo recentes uma mensagema partir de um dispositivo final pai, por meio do que odado dispositivo final foi sincronizado. Preferencialmente,por essa metodologia, se ele tiver sido, então, um sinal deaceitação de sincronização será transmitido para odispositivo final não sincronizado requisitante. Caso elenão tenha sido, então, ao invés disso, um sinal derequisição de sinal de orientação é transmitido para umdispositivo final pai registrado.
Uma metodologia de exemplo presente adicional serefere a uma metodologia para permitir que um dispositivofinal de rede estabeleça um enlace com uma rede de salto defreqüência de sistema de medição avançado existente. Essapresente modalidade de exemplo preferencialmente podecompreender a provisão de uma sistema de alinhamento defolha incluindo uma instalação central e uma pluralidade dedispositivos finais, pelo menos alguns desses dispositivosfinais compreendendo dispositivos de metrologia; aconfiguração da rede para comunicações bidirecionais entrea instalação central e cada um da pluralidade dedispositivos finais; fazer com que um dispositivo finalregistrado previamente, o qual perdeu sua sincronização coma rede, transmita uma requisição de sinal de orientaçãopara um dispositivo final vizinho; e a configuração dodispositivo final vizinho para transmitir uma informação desincronização para o dispositivo final previamenteregistrado, se o dispositivo final vizinho tiver recebidoem um número predeterminado de intervalos de tempo recentesuma mensagem a partir de um dispositivo final pai pelo qualo dispositivo final vizinho foi sincronizado.
Uma presente modalidade de exemplo relativa ao assuntode rede preferencialmente pode incluir uma rede de salto defreqüência de sistema de medição avançado, compreendendouma instalação central; uma pluralidade de dispositivosfinais, pelo menos alguns desses dispositivos finaiscompreendendo dispositivos de metrologia, com a referidainstalação central e a referida pluralidade de dispositivosfinais sendo configuradas para comunicações bidirecionaisentre si; e pelo menos um dispositivo final capaz dereceber uma requisição de sincronização a partir de umdispositivo final vizinho não sincronizado. Ainda, pelomenos um dispositivo final como esse preferencialmente podeser configurado, mediante o recebimento de uma requisiçãode sincronização a partir de um dispositivo final vizinhonão sincronizado, para determinar se ele recebeu em umnúmero predeterminado de intervalos de tempo recentes umamensagem a partir de um dispositivo final de nível maisalto por meio do que pelo menos um dispositivo final foisincronizado. Se assim for, então, preferencialmente, umsinal de aceitação de sincronização é transmitido para odispositivo final vizinho não sincronizado. Caso não,então, preferencialmente um sinal de requisição de sinal deorientação é transmitido para um dispositivo final de nívelmais alto registrado.
Uma presente modalidade de exemplo se refere a umametodologia para uma rede de malha de sistema de mediçãoavançado com um gerenciamento de vizinhança adaptativo deenlaces de comunicação, compreendendo o estabelecimento deuma rede que inclui uma instalação central e umapluralidade de dispositivos de nó, pelo menos alguns dessesdispositivos de nó compreendendo dispositivos demetrologia, e pelo menos alguns desses dispositivos de nócompreendem dispositivos de nó pai os quais provêem umenlace de comunicações para outros dos dispositivos de nódefinindo dispositivos de nó filho de um dado respectivodispositivo de nó pai; a configuração da rede paracomunicações bidirecionais entre a instalação central ecada um da pluralidade de dispositivos de nó através deassociações com respectivos dos dispositivos de nó pai; apartir de cada dispositivo de nó filho existente associadoa um dado dispositivo de nó pai específico, a provisão deuma informação para esse dado dispositivo de nó paiespecífico sobre enlaces de comunicações pais alternativosdisponíveis para esse dispositivo de nó filho existente;para cada dispositivo de nó pai, mediante o recebimento deuma requisição a partir de um dispositivo de nó não filhopara se tornar um dispositivo de nó filho do mesmo, aavaliação dessa informação a partir de seus dispositivos denó filho existentes e a avaliação de sua capacidade paraaceitar um novo dispositivo de nó filho e, se tiver essacapacidade, a aceitação desse dispositivo de nó não filhorequisitante como um novo dispositivo de nó filho do mesmo,ou, caso não tenha essa capacidade, a remoção de seusdispositivos de nó filho existentes de um dispositivo de nófilho existente o qual indicou um enlace de comunicaçõespai alternativo disponível para ele e, então, a aceitaçãodesse dispositivo de nó não filho requisitante como um novodispositivo de nó filho do mesmo.
Uma outra presente modalidade de exemplo maisparticularmente se refere a uma metodologia para uma redede malha de sistema de medição avançado com gerenciamentoadaptativo de enlaces de comunicações de pai - filho,compreendendo o estabelecimento de uma rede incluindo umainstalação central e uma pluralidade de dispositivos de nó,pelo menos alguns desses dispositivos de nó compreendendodispositivos de metrologia, pelo menos alguns dessesdispositivos de nó compreendendo mestres de célula os quaisprovêem comunicações entre a instalação central e outrosdos dispositivos de nó associados a ele em respectivascélulas formadas por cada respectivo mestre de célula, epelo menos alguns desses dispositivos de nó compreendendodispositivos de nó pai os quais provêem um enlace decomunicações sincronizado entre um respectivo mestre decélula e outros dos dispositivos de nó definindodispositivos de nó filho de um dado respectivo dispositivode nó pai; a configuração da rede para comunicaçõesbidirecionais entre a instalação central e cada um dapluralidade de dispositivos de nó através de associaçõescom os respectivos dispositivos de nó pai e os mestres decélula; em cada dispositivo de nó, o estabelecimento e aatualização de uma informação sobre cada um dessesdispositivos de nó e suas respectivas relações de vizinho eenlaces de comunicações, incluindo uma notificação deindicador tipo de flag confirmando que esse dispositivo denó tem disponíveis para ele pais potenciais acima de umnúmero predeterminado dos mesmos, cada um dessesdispositivos de nó incluindo essa notificação de indicadortipo de flag conforme aplicável em suas transmissões; emcada dispositivo de nó pai, a monitoração dessasnotificações de indicador tipo de flag a partir de seusdispositivos de nó filho existentes, e mediante orecebimento de uma requisição de sincronização a partir deum dispositivo de nó não filho quanto a se tornar umdispositivo de nó filho do mesmo, a avaliação dessasnotificações de indicador tipo de flag a partir de seusdispositivos de nó filhos existentes e a avaliação de suacapacidade para aceitar um novo dispositivo de nó filho, ese tiver essa capacidade, a sincronização com essedispositivo de nó não filho requisitante como um novodispositivo de nó filho do mesmo, ou se não tiver essacapacidade, a remoção de seus dispositivos de nó filhosexistentes de um dispositivo de nó filho existente o qualatravés de sua notificação de indicador tipo de flagindicou um enlace de comunicação pai alternativo disponívelpara ele, o envio de uma notificação de remoção para essedispositivo de nó filho existente sendo removido, e asincronização com esse dispositivo de nó não filhorequisitante como um novo dispositivo de nó filho do mesmo,por meio do que dispositivos de nó não filhos não sãorecusados para sincronização na rede.
Ainda uma outra modalidade de exemplo presente estárelacionada a uma rede de malha de sem com um gerenciamentode visualização adaptativo de enlaces de comunicações,compreendendo uma instalação central; e uma pluralidade dedispositivos de nó, pelo menos alguns desses dispositivosde nó compreendendo dispositivos de metrologia, e pelomenos alguns desses dispositivos de nó compreendendodispositivos de nó pai os quais provêem um enlace decomunicações para outros desses dispositivos de nódefinindo dispositivos de nó filho de um dado respectivodispositivo de nó pai, com essa rede configurada paracomunicações bidirecionais entre essa instalação central ecada um dessa pluralidade de dispositivos de nó através deassociações com respectivos desses dispositivos de nó pai.
Com uma modalidade de exemplo, preferencialmente cadadispositivo de nó filho existente associado a um dadodispositivo de nó pai específico é adicionalmenteconfigurado para prover uma informação para esse dadodispositivo de nó pai específico sobre enlaces decomunicações de pais alternativos disponíveis para essedispositivo de nó filho existente; cada dispositivo de nópai ainda é configurado para, mediante o recebimento de umarequisição a partir de um dispositivo de nó não filho,tornar-se um dispositivo de nó filho do mesmo, paraavaliação dessa informação a partir de seus dispositivos denó filho existentes e avaliação de sua capacidade paraaceitação de um novo dispositivo de nó filho e, se tiveressa capacidade, a aceitação desse dispositivo de nó nãofilho requisitante como um novo dispositivo de nó filho domesmo ou, caso não tenha essa capacidade, a remoção de seusdispositivos de nó filho existentes de um dispositivo de nófilho existente o qual indicou um enlace de comunicaçõespai alternativo para ele e, então, a aceitação dessedispositivo de nó não filho requisitante como um novodispositivo de nó filho do mesmo.
Ainda uma outra modalidade de exemplo presente serefere a uma rede de malha de sistema de medição avançadocom gerenciamento adaptativo de enlaces de comunicações depai - filho, compreendendo uma instalação central; e umapluralidade de dispositivos de nó, pelo menos alguns dessesdispositivos de nó compreendendo dispositivos demetrologia, pelo menos alguns desses dispositivos de nócompreendendo mestres de célula os quais provêemcomunicações entre a instalação central e outros dosdispositivos de nó associados a ele em respectivas célulasformadas por cada respectivo mestre de célula, e pelo menosalguns desses dispositivos de nó compreendendo dispositivosde nó pai os quais provêem um enlace de comunicaçõessincronizado entre um respectivo mestre de célula e outrosdos dispositivos de nó definindo dispositivos de nó filhode um dado respectivo dispositivo de nó pai, com essa redeconfigurada para comunicações bidirecionais entre essainstalação central e cada um dessa pluralidade dedispositivos de nó através de associações com osrespectivos dispositivos de nó pai e os mestres de célula.Por essa modalidade, preferencialmente, cada dispositivo denó é configurado para o estabelecimento e a atualização deuma informação sobre cada um desses dispositivos de nó esuas respectivas relações de vizinho e enlaces decomunicações, incluindo uma notificação de indicador tipode flag confirmando que esse dispositivo de nó temdisponíveis para ele pais potenciais acima de um númeropredeterminado dos mesmos, e ainda é configurado paraincluir essa notificação de indicador tipo de flag conformeaplicável em suas transmissões; cada dispositivo de nó paiainda é configurado para a monitoração dessas notificaçõesde indicador tipo de flag a partir de seus dispositivos denó filho existentes, e mediante o recebimento de umarequisição de sincronização a partir de um dispositivo denó não filho quanto a se tornar um dispositivo de nó filhodo mesmo, a avaliação dessas notificações de indicador tipode flag a partir de seus dispositivos de nó filhosexistentes e a avaliação de sua capacidade para aceitar umnovo dispositivo de nó filho, e se tiver essa capacidade, asincronização com esse dispositivo de nó não filhorequisitante como um novo dispositivo de nó filho do mesmo,ou se não tiver essa capacidade, a remoção de seusdispositivos de nó filhos existentes de um dispositivo denó filho existente o qual através de sua notificação deindicador tipo de flag indicou um enlace de comunicação paialternativo disponível para ele, o envio de uma notificaçãode remoção para esse dispositivo de nó filho existentesendo removido, e a sincronização com esse dispositivo denó não filho requisitante como um novo dispositivo de nófilho do mesmo, por meio do que dispositivos de nó nãofilhos não são recusados para sincronização na rede.
Uma modalidade de exemplo adicional presente maisparticularmente se refere a um dispositivo de metrologiapara uso com uma rede de malha de sistema de mediçãoavançado com gerenciamento de vizinhança adaptativo deenlaces de comunicações e incluindo uma instalação central,uma pluralidade de dispositivos de nó, com pelo menosalguns desses dispositivos de nó compreendendo essesdispositivos de metrologia, e pelo menos alguns dessesdispositivos de nó compreendendo dispositivos de nó paiprovendo enlaces de comunicações sincronizados para outrosdos dispositivos de nó definindo dispositivos de nó filhode um dado respectivo dispositivo de nó pai, com cadadispositivo de nó configurado para comunicações com essainstalação central através de associações com respectivosdos dispositivos de nó pai. Um dispositivo de metrologia deexemplo como esse preferencialmente pode compreender umaporção de metrologia configurada para a medição do consumode um bem de consumo de serviço de utilidade pública; umaporção de transmissor configurado para a transmissão de umainformação de consumo e de outros dados; e uma porção dereceptor configurada para receber uma informação a partirde outros dispositivos de rede em uma rede associada. Aindapreferencialmente, essas porções de dispositivo demetrologia são configuradas para a provisão para seurespectivo dispositivo de nó pai em uma rede associada deuma informação sobre enlaces de comunicações paisalternativos disponíveis para esse dispositivo demetrologia nessa rede associada, de modo que esserespectivo dispositivo de nó pai possa fazer determinaçõessobre a remoção desse dispositivo de metrologia como umfilho do mesmo no lugar de outros dispositivos de nó nessarede associada.
Uma presente modalidade de exemplo se refere a ummétodo para a compensação de uma deriva em relógios dedispositivo de nó em uma rede de malha de sistema demedição avançado. Um método de exemplo como esse podecompreender o estabelecimento de uma rede incluindo pelomenos um nó de raiz e uma pluralidade de dispositivos denó, pelo menos alguns desses dispositivos de nócompreendendo dispositivos de metrologia; a configuração darede para comunicações bidirecionais dentre pelo menos umnó de raiz e cada um da pluralidade de dispositivos de nó;a provisão de cada dispositivo de nó com um relógio internocontrolado por cristal; a condução de comunicações depacote dentre o nó de raiz e a pluralidade de dispositivosde nó; e a configuração de cada dispositivo de nó pararealinhamento de seu relógio interno a cada vez em que odispositivo de nó se comunicar com um outro dispositivo denó mais próximo do nó de raiz do que ele mesmo. Por essametodologia de exemplo, cada um desses dispositivos de nórealinhará seu relógio para estar em sincronização com arede, desse modo compensando diferenças de tempo causadaspela deriva em qualquer um dos relógios de dispositivo denó.
Uma outra modalidade de exemplo presente se refere,mais particularmente, a um método para a compensação de umaderiva de freqüência de cristal em uma rede de malha desistema de medição avançado. Uma metodologia como essepreferencialmente pode compreender o estabelecimento de umarede incluindo pelo menos um nó de raiz e uma pluralidadede dispositivos de nó, pelo menos alguns dessesdispositivos de nó compreendendo dispositivos demetrologia; a configuração da rede para comunicaçõesbidirecionais dentre pelo menos um nó de raiz e cada um dapluralidade de dispositivos de nó; a provisão de cada um dapluralidade de dispositivos de nó com um relógio internocontrolado por cristal; a condução de comunicações dentre onó de raiz e a pluralidade de dispositivos de nó usando-seum hiperquadro de repetição subdividido em um protocolo depacote de intervalo de tempo de repetição; e a configuraçãode cada dispositivo de nó para ressincronização de seurelógio interno a cada vez em que o nó se comunicar com onó de raiz ou com um outro nó mais próximo do que ele mesmodo nó de raiz. Por essa modalidade de exemplo, essedispositivo de nó realinhará seu relógio interno para estarem sincronização com a rede, desse modo compensando umaderiva de freqüência de cristal.
Ainda uma outra modalidade de exemplo presente serefere a uma rede de malha de sistema de medição avançadoque compreende pelo menos um nó de raiz; uma pluralidade dedispositivos de nó, pelo menos alguns desses dispositivosde nó compreendendo dispositivos de metrologia, essapluralidade de dispositivos de nó configurada paracomunicações bidirecionais dentre pelo menos um nó de raize outros dessa pluralidade de dispositivos de nó usando-seum hiperquadro de repetição subdividido em um protocolo depacote de seqüência de intervalo de tempo de repetição; euma pluralidade de relógios internos controlados porcristal, respectivamente associados a cada um dessapluralidade de dispositivos de nó. Por essa modalidade deexemplo, preferencialmente cada um desses dispositivos denó é configurado para ressincronização de seu respectivorelógio interno a cada vez em que esse respectivodispositivo de nó se comunicar com pelo menos um nó de raizou um outro dispositivo de nó mais próximo do que ele mesmopelo menos desse nó de raiz, por meio do que esserespectivo dispositivo de nó realinhará seu relógio internopara estar era sincronização com a rede. Com essamodalidade, uma deriva de freqüência de cristal écompensada.
Uma presente modalidade de exemplo se refere a ummétodo para a distribuição de uma informação para nós emuma direção de máquina de sistema de medição avançado. Essemétodo de exemplo pode compreender, preferencialmente, oestabelecimento de uma rede de malha que inclui pelo menosum nó mestre e uma pluralidade de dispositivos de nó, pelomenos alguns desses dispositivos de nó compreendendodispositivos de metrologia; a configuração da rede paracomunicações bidirecionais dentre pelo menos um nó mestre ecada um da pluralidade de dispositivos de nó usando-se umhiperquadro de repetição subdividido em um protocolo depacote de intervalo de tempo de repetição; a atribuição dení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 distantesdo nó mestre sejam atribuídos números mais altos; aidentificação em cada nó de nós vizinhos do mesmo, onde osvizinhos com um nível mais baixo são identificados como ospais do nó, os vizinhos tendo um nível igual sãoidentificados como irmãos, e os vizinhos tendo um nívelmais alto são identificados como filhos; a difusão de umamensagem a partir do nó mestre para os nós de nível maisalto; e a atribuição de seqüências de reconhecimento a nósfilhos em mensagens difundidas pelos nós pais. Com essametodologia, os filhos falhando em receber mensagensdifundidas 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 deinformação para nós em uma rede de malha de sistema demedição avançado. Um método de exemplo como essepreferencialmente pode compreender o estabelecimento de umarede de malha que inclui pelo menos um nó mestre e umapluralidade de dispositivos de nó, pelo menos alguns dessesdispositivos de nó compreendendo dispositivos demetrologia; a configuração da rede para comunicaçõesbidirecionais dentre pelo menos um nó mestre e cada um dapluralidade de dispositivos de nó usando-se um hiperquadrode repetição subdividido em um protocolo de pacote deintervalo de tempo de repetição; a atribuição de níveis acada nó com base no número de saltos que o nó está distantedo nó mestre, de modo que aos nós mais distantes do nómestre sejam atribuídos números mais altos; a identificaçãoem cada nó de nós vizinhos do mesmo, onde os vizinhos comum nível mais baixo são identificados como os pais do nó,os vizinhos tendo um nível igual são identificados comoirmãos, e os vizinhos tendo um nível mais alto sãoidentificados como filhos; a difusão de mensagens a partirde nós pais para nós filhos como seqüências emparelhadas.Vantajosamente, pela prática desse método de exemplo, aprimeira mensagem na seqüência emparelhada especifica umaordem de resposta para nós filhos e a segunda mensageminclui uma identificação de difusão.
Ainda uma outra modalidade de exemplo presente serefere a uma rede de malha de sistema de medição avançado,que compreende pelo menos um nó mestre; e uma pluralidadede dispositivos de nó, pelo menos alguns dessesdispositivos de nó compreendendo dispositivos demetrologia, com essa pluralidade de dispositivos de nóconfigurada para comunicações bidirecionais dentre pelomenos esse dispositivo de metrologia e cada um dapluralidade de dispositivos de nó usando um hiperquadro derepetição subdividido em um protocolo de pacote deintervalo de tempo de repetição. Preferencialmente, poressa modalidade, cada respectivo nó é configurado para teratribuído um nível com base no número de saltos que o nóestá distante de pelo menos esse nó mestre, e para aidentificação de nós vizinhos tendo um nível mais baixocomo nós pais, vizinhos tendo um nível igual como nósirmãos, e vizinhos tendo um nível mais alto como nósfilhos; esses nós pais configurados para a difusão demensagens para nós filhos como seqüências emparelhadas comuma primeira mensagem especificando uma ordem de respostapara nós filhos e uma segunda mensagem incluindo umaidentificação de difusão.
Uma presente modalidade doa metodologia em questão serefere a uma metodologia para uma rede de malha de sistemade medição avançado com um gerenciamento de carga detráfego de auto-ajuste, compreendendo o estabelecimento deuma rede que inclui uma instalação central e umapluralidade de dispositivos de nó, pelo menos alguns dessesdispositivos de nó compreendendo dispositivos demetrologia, e pelo menos alguns desses dispositivos de nócompreendendo nós de extração de dados, os quais provêemcomunicações pelo menos em uma direção de enlace ascendenteentre outros dos dispositivos de nó e a instalação central;a configuração da rede para comunicações bidirecionaisentre a instalação central e cada um da pluralidade dedispositivos de nó; a monitoração e o cálculo da respectivadensidade de tráfego em uma direção de enlace ascendentecom referência a cada respectivo dispositivo de nó; e ocontrole do sincronismo das respectivas transmissões em umadireção de enlace ascendente de cada respectivo dispositivode nó com base em seu respectivo cálculo de densidade detráfego. Com a prática dessa metodologia, esse cálculo dedensidade de tráfego permanece abaixo de um limite de redepredeterminado.
Uma outra metodologia de exemplo presente se refere auma metodologia para uma rede de malha de salto defreqüência de Aloha com intervalo de sistema de mediçãoavançado com gerenciamento de carga de tráfego de auto-ajuste. Essa modalidade de exemplo preferencialmentecompreende o estabelecimento de uma rede incluindo umainstalação central e uma pluralidade de dispositivos de nó,pelo menos alguns desses dispositivos de nó compreendendodispositivos de metrologia, e pelo menos alguns dessesdispositivos de nó compreendendo dispositivos de nó pai, osquais provêem comunicações pelo menos em uma direção deenlace ascendente entre outros dos dispositivos de nó e ainstalação central; a configuração da rede paracomunicações bidirecionais entre a instalação central ecada um da pluralidade de dispositivos de nó através deassociações com respectivos dispositivos de nó pai; adeterminação de uma taxa de sucesso de comunicação médiapara cada dispositivo de nó pai com referência a cadarespectivo dispositivo de nó e a observação dereconhecimentos de comunicações a partir desse dispositivode nó pai com referência a esse respectivo dispositivo denó; o controle do sincronismo de respectivas transmissõesem uma direção de enlace ascendente de cada respectivodispositivo de nó com base em seu respectivo cálculo dedensidade de tráfego, de modo que esse cálculo de densidadede tráfego permaneça abaixo de um limite de redepredeterminado, com transmissões de enlace ascendenteenviadas em um tempo randômico em uma janela derandomização, cujo comprimento Tw de janela de randomizaçãose 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ó paiA, e Rmax é uma densidade de entrada de tráfego máximapredeterminada para esse dispositivo de nó pai A; e oarmazenamento em buffer de transmissões de enlaceascendente em cada respectivo dispositivo de nó até umatransmissão controlada do mesmo.
Uma outra modalidade de exemplo presente se refere,mais particularmente, a uma rede de malha de sistema demedição avançado com gerenciamento de carga de tráfego deauto-ajuste. Essa modalidade de exemplo pode compreenderuma instalação central; e uma pluralidade de dispositivosde nó, pelo menos alguns desses dispositivos de nócompreendendo dispositivos de metrologia, e pelo menosalguns desses dispositivos de nó compreendendo nós deextração de dados, os quais provêem comunicações pelo menosem uma direção de enlace ascendente entre outros dessesdispositivos de nó e a instalação central, com cadadispositivo de nó configurado para comunicaçõesbidirecionais com essa instalação central. Nessa modalidadede exemplo, preferencialmente cada um desses dispositivosde nó é configurado para a monitoração e o cálculo darespectiva densidade de tráfego em uma direção de enlaceascendente com referência a cada respectivo dispositivo denó, e para controle do sincronismo de respectivastransmissões em uma direção de enlace ascendente de cadarespectivo dispositivo de nó com base em seu respectivocálculo de densidade de tráfego, de modo que esse cálculode densidade de tráfego permaneça abaixo de um limite derede predeterminado.
Ainda uma outra modalidade de exemplo presente serefere a uma rede de malha de salto de freqüência de Alohacom intervalo de sistema de medição avançado comgerenciamento de carga de tráfego de auto-ajuste. Essamodalidade de exemplo preferencialmente pode compreenderuma instalação central; e uma pluralidade de dispositivosde nó, pelo menos alguns desses dispositivos de nócompreendendo dispositivos de metrologia, e pelo menosalguns desses dispositivos de nó compreendem dispositivosde nó pai os quais provêem comunicações pelo menos em umadireção de enlace ascendente entre outros dessesdispositivos de nó e a instalação central, com essa redeconfigurada para comunicações bidirecionais entre essainstalação central e cada um dessa pluralidade dedispositivos de nó através de associações com respectivosdesses dispositivos de nó pai. Preferencialmente, cada umdesses dispositivos de nó é configurado para a determinaçãode uma taxa de sucesso de comunicação média para cadadispositivo de nó pai com referência a cada respectivodispositivo de nó e a observação de reconhecimentos decomunicações a partir desse dispositivo de nó pai e, combase nisso, o cálculo da respectiva densidade de tráfego decada um desses dispositivos de nó pai co referência a cadaum desses respectivos dispositivos de nó; e para controledo sincronismo de respectivas transmissões em uma direçãode 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çaabaixo de um limite de rede predeterminado, comtransmissões de enlace ascendente enviadas em um temporandô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ó paiA, e Rmax é uma densidade de entrada de tráfego máximapredeterminada para esse dispositivo de nó pai A; e para oarmazenamento em buffer de transmissões de enlaceascendente em cada respectivo dispositivo de nó até umatransmissão controlada disso.
Ainda uma outra modalidade de exemplo presente serefere, mais particularmente, a um dispositivo demetrologia para uso com uma rede de malha de salto defreqüência de Aloha com intervalo de sistema de mediçãoavançado com gerenciamento de carga de tráfego de auto-ajuste, e incluindo uma instalação central, uma pluralidadede dispositivos de nó, com pelo menos alguns dessesdispositivos de nó compreendendo dispositivos de nó pai osquais provêem comunicações pelo menos em uma direção deenlace ascendente entre outros dos dispositivos de nó e ainstalação central, com cada dispositivo de nó configuradopara comunicações bidirecionais com essa instalação centralatravés de pelo menos um desses dispositivos de nó paiassociados. Esse dispositivo de metrologia de exemplopreferencialmente pode compreender uma porção de metrologiaconfigurada para a medição do consumo de um bem de consumode serviço de utilidade pública; uma porção de transmissorconfigurada para a transmissão de uma informação de consumoe de outros dados; e uma porção de receptor configuradapara receber uma informação de outros dispositivos de redeem uma rede associada. Ainda, essa porção de transmissor eessa porção de receptor preferencialmente são configuradaspara a monitoração e o cálculo da respectiva densidade detráfego em uma direção de enlace ascendente a partir daliem uma rede associada e para controle do sincronismo derespectivas transmissões em uma direção de enlaceascendente a partir dali, com base nesse cálculo dedensidade de tráfego. Com essa modalidade de exemplo, essecálculo de densidade de tráfego permanece abaixo de umlimite predeterminado de uma rede associada.
Uma modalidade de exemplo da presente metodologia serefere a uma metodologia para uma rede de malha de sistemade medição avançado com ferramentas de avaliação ambientalde RF embutidas. Essa metodologia preferencialmente podecompreender o estabelecimento de uma rede que inclui umainstalação central e uma pluralidade de dispositivos de nó,pelo menos alguns desses dispositivos de nó compreendendodispositivos de metrologia, e pelo menos alguns dessesdispositivos de nó compreendendo relês de célula os quaisprovêem comunicações entre outros dos dispositivos de nó ea instalação central; a configuração da rede paracomunicações bidirecionais entre a instalação central ecada um da pluralidade de dispositivos de nó; a monitoraçãoseletiva de dados de Indicador de Intensidade de SinalRecebido (RSSI) em cada respectivo dispositivo de nó; e orelatório desses dados de RSSI a partir de respectivosdispositivos de nó para a instalação central. Com a práticadessa metodologia, as condições do ambiente de RF no qualessa rede reside podem ser avaliadas.
Uma outra modalidade de exemplo presente se refere auma metodologia mais particularmente relativa a umametodologia para uma rede de malha de salto de freqüênciade sistema de medição avançado com ferramentas de avaliaçãoambiental de RF embutidas para calibração das necessidadesde performance de transceptor de RF dessa rede. Essametodologia de exemplo pode compreender o estabelecimentode uma rede que inclui uma instalação central e umapluralidade de dispositivos de nó, pelo menos alguns dessesdispositivos de nó compreendendo dispositivos demetrologia, e pelo menos alguns desses dispositivos de nócompreendendo relês de célula os quais provêem comunicaçõesentre outros dos dispositivos de nó e a instalação central;a configuração da rede para comunicações bidirecionaisentre a instalação central e cada um da pluralidade dedispositivos de nó através de associações com respectivosrelês de célula; a tomada de leituras seletivamente deIndicador de Intensidade de Sinal Recebido (RSSI) emrespectivos dispositivos de nó; a realização de uma análiseestatística em cada um desses respectivos dispositivos denó para computação de dados de RSSI médio e dados de funçãode autocorrelação de RSSI com base em leituras de RSSI emcada um desses respectivos dispositivos de nó; e orelatório desses dados de RSSI médios computados e de dadosde função de autocorrelação de RSSI para a instalaçãocentral para uso na análise das características de tempo deinterferência de RF, com base na experiência de ambienteeletromagnético de dispositivo de nó para dispositivo de nóreal da rede.
Ainda uma outra modalidade de exemplo presente serrefere a uma rede de malha de sistema de medição avançadocom ferramentas de avaliação ambiental de RF embutidas.
Essa rede pode compreender, preferencialmente, umainstalação central; e uma pluralidade de dispositivos denó, pelo menos alguns desses dispositivos de nócompreendendo dispositivos de metrologia; e pelo menosalguns desses dispositivos de nó compreendem relês decélula os quais provêem comunicações entre outros dessesdispositivos de nó e a instalação central, com cadadispositivo de nó configurado para comunicaçõesbidirecionais com essa instalação central. Ainda,preferencialmente cada um desses dispositivos de nó éconfigurado para a monitoração seletiva de dados deIndicador de Intensidade de Sinal Recebido (RSSI) em cadarespectivo dispositivo de nó e relatar esses dados de RSSIa partir dali para a instalação central, de modo que ascondições do ambiente de resfriamento em que essa redereside possam ser avaliadas.
Ainda uma outra modalidade de exemplo presente serefere a uma rede de malha de salto de freqüência desistema de medição avançado com ferramentas de avaliaçãoambiental de RF embutidas para calibração das necessidadesde performance de transceptor de RF dessa rede. Essa redede exemplo pode compreender preferencialmente umainstalação central; e uma pluralidade de dispositivos denó, pelo menos alguns desses dispositivos de nócompreendendo dispositivos de metrologia, e pelo menosalguns desses dispositivos de nó compreendendo relês decélula os quais provêem comunicações entre outros dessesdispositivos de nó e a instalação central, com essa redeconfigurada para comunicações bidirecionais entre ainterface de lado de cliente e cada um dessa pluralidade dedispositivos de nó através de associações com respectivosdesses relês de célula. Mais ainda, preferencialmente cadaum desses dispositivos de nó é configurado paraseletivamente tomar leituras de Indicador de Intensidade deSinal Recebido (RSSI) ali, realizar uma análise estatísticaali para computação dos dados de RSSI médios e de dados defunção de autocorrelação de RSSI, com base em leituras deRSSI ali, e reportar esses dados de RSSI médios computadose dados de função de autocorrelação de RSSI para ainstalação central para uso na análise de característicasde tempo de interferência de RF, com base na experiência deambiente eletromagnético de dispositivo de nó paradispositivo de nó real da rede.
Uma modalidade de exemplo presente adicional maisparticularmente se refere a um dispositivo de metrologia.Esse dispositivo de metrologia preferencialmente é para usocom uma rede de malha de salto de freqüência de sistema demedição avançado com ferramentas de avaliação ambiental deRF embutidas para calibração das necessidades deperformance de transceptor de RF dessa rede, e incluindouma instalação central, uma pluralidade de dispositivos denó, com pelo menos alguns desses dispositivos de nócompreendendo esses dispositivos de metrologia, e pelomenos alguns desses dispositivos de nó compreendendo relêsde célula operando por sua própria respectiva seqüência decanais e provendo comunicações entre outros dosdispositivos de nó e a instalação central, com cadadispositivo de nó configurado para comunicaçõesbidirecionais com essa instalação central através de pelomenos um relê associado desses relês de célula. Umdispositivo de metrologia de exemplo como esse podecompreender uma porção de metrologia configurada para amedição do consumo de um bem de consumo de serviço deutilidade pública; uma porção de transmissor configuradapara a transmissão de uma informação de consumo e de outrosdados; e uma porção de receptor configurada para receberuma informação a partir de outros dispositivos de rede emuma rede associada. Preferencialmente, essas porções dedispositivo de metrologia são configuradas para amonitoração seletiva de dados de Indicador de Intensidadede Sinal Recebido (RSSI) ali, e reportar esses dados deRSSI a partir dali para a instalação central de uma redeassociada, de modo que as condições do ambiente de RF noqual essa rede reside possam ser avaliadas.
Uma modalidade de exemplo presente se refere a umametodologia para uma rede de malha de sistema de mediçãoavançado com roteamento de enlace descendente de modomúltiplo. Essa modalidade pode compreender,preferencialmente, o estabelecimento de uma rede incluindouma instalação central e uma pluralidade de dispositivos denó, pelo menos alguns desses dispositivos de nócompreendendo dispositivos de metrologia, e pelo menosalguns desses dispositivos de nó compreendendo mestres decélula os quais provêem comunicações entre a instalaçãocentral e outros dos dispositivos de nó associados a elesnas respectivas células formadas por cada respectivo mestrede célula; a configuração da rede para comunicaçõesbidirecionais entre a instalação central e cada um dapluralidade de dispositivos de nó; a partir de cadadispositivo de nó associado a um dado mestre de célulaespecifico em uma respectiva célula formada dessa forma, aprovisão de uma informação para esse dado mestre de célulaespecífico sobre enlaces de comunicações de cada um dessesdispositivos de nó nessa respectiva célula; o envioseletivo de uma mensagem de enlace descendente demonodifusão a partir de um dado respectivo mestre de célulapara um dispositivo de nó específico associado a ele,usando um percurso de enlace descendente de monodifusãodeterminado por esse dado respectivo mestre de célula combase em sua informação recebida a partir de todos osdispositivos de nó associados a ele; e o envio seletivo deuma mensagem de enlace descendente de difusão a partir deum dado respectivo mestre de célula para todos osdispositivos de nó associados a ele.
Uma outra modalidade de exemplo de metodologiapresente se refere a uma rede de malha de salto defreqüência de sistema de medição avançado com um roteamentode enlace descendente de modo múltiplo dinâmico para todosos dispositivos de nó da mesma. Essa modalidadepreferencialmente pode compreender uma metodologia para oestabelecimento de uma rede incluindo uma instalaçãocentral e uma pluralidade de dispositivos de nó, pelo menosalguns desses dispositivos de nó compreendendo dispositivosde metrologia, pelo menos alguns desses dispositivos de nócompreendendo mestres de célula os quais provêemcomunicações entre a instalação central e outros dosdispositivos de nó associados a eles em respectivas célulasformadas por cada respectivo mestre de célula, e pelo menosalguns desses dispositivos de nó compreendem dispositivosde nó pais os quais provêem um enlace de comunicações entreum respectivo mestre de célula e outros dos dispositivos denó definindo dispositivos de nó filhos de um dadorespectivo dispositivo de nó pai na respectiva célula dorespectivo mestre de célula; a configuração da rede paracomunicações bidirecionais entre a instalação central ecada um da pluralidade de dispositivos de nó através deassociações com respectivos mestres de célula; em cadadispositivo de nó, a manutenção de uma tabela de vizinhocontendo uma informação sobre cada um desses dispositivosde nó e suas respectivas relações de vizinho e enlaces decomunicações em uma respectiva célula formada por umrespectivo mestre de célula; a partir de cada dispositivode nó associado a um dado mestre de célula especifico emuma respectiva célula formada dessa forma, o encaminhamentoda tabela de vizinho do mesmo para esse dado mestre decélula específico; em cada dispositivo de nó associado a umdado mestre de célula específico em uma respectiva célulaformada dessa forma, a atualização de sua respectiva tabelade vizinho quando quaisquer mudanças ocorrerem em qualqueruma de suas respectivas relações de vizinho ou enlaces decomunicações, e o encaminhamento dessa tabela de vizinhoatualizada do mesmo para esse mestre de célula específico;o envio seletivo de uma mensagem de enlace descendente dedifusão a partir de um dado respectivo mestre de célulapara todos os dispositivos de nó associados a ele em suarespectiva célula; e o envio seletivo de uma mensagem deenlace descendente de monodifusão a partir de um dadorespectivo mestre de célula para um dispositivo de nóespecífico associado a ele na respectiva célula formada poresse dado respectivo mestre de célula, usando-se umpercurso de enlace descendente de monodifusão determinadopor esse dado respectivo mestre de célula, com base emtabelas de vizinho recebidas a partir de todos osdispositivos de nó associados a ele em sua respectivacélula. Com essa modalidade, essa rede adapta dinamicamenteseu roteamento de enlace descendente a mudanças em enlacesde comunicações dentre os dispositivos de nó da mesma.
Ainda uma outra modalidade de exemplo presente serefere a uma rede de malha de sistema de medição avançadocom roteamento de enlace descendente de modo múltiplo. Umamodalidade como essa preferencialmente compreende umainstalação central; e uma pluralidade de dispositivos denó, pelo menos alguns desses dispositivos de nócompreendendo dispositivos de metrologia, e pelo menosalguns desses dispositivos de nó compreendendo mestres decélula os quais provêem comunicações entre a referidainstalação central e outros dos referidos dispositivos denó associados a ele em respectivas células formadas porcada respectivo mestre de célula, com cada dispositivo denó configurado para comunicações bidirecionais com areferida instalação central. Nessa modalidade,preferencialmente, cada um dos referidos dispositivos de nóé configurado para prover uma informação para seurespectivo mestre de célula sobre enlaces de comunicaçõesdo mesmo nessa respectiva célula; e cada respectivo mestrede célula é configurado para seletivamente enviar umamensagem de enlace descendente de monodifusão a partir delepara um dispositivo de nó específico associado a ele,usando um percurso de enlace descendente de monodifusãodeterminado por ele com base em sua informação recebida apartir de todos os dispositivos de nó associados a ele, eainda é configurado para seletivamente enviar uma mensagemde enlace descendente de difusão a partir dele para todosos dispositivos de nó associados a ele.
Em uma outra modalidade de exemplo presente, uma redede malha de salto de freqüência de sistema de mediçãoavançado tem um roteamento de enlace descendente de modomúltiplo dinâmico para todos os dispositivos de nó damesma. Essa rede preferencialmente compreende umainstalação central; e uma pluralidade de dispositivos denó, pelo menos alguns desses dispositivos de nócompreendendo dispositivos de metrologia, pelo menos algunsdesses dispositivos de nó compreendendo mestres de célula,os quais provêem comunicações entre a referida instalaçãocentral e outros dos referidos dispositivos de nóassociados a isso nas respectivas células formadas por cadarespectivo mestre de célula, e pelo menos alguns dessesdispositivos de nó compreendendo dispositivos de nó pais osquais provêem um enlace de comunicações entre um respectivomestre de célula e outros dos referidos dispositivos de nódefinindo dispositivos de nó filhos de um dado respectivodispositivo de nó pai na respectiva célula do respectivomestre de célula, com cada um dos referidos dispositivos denó configurado para comunicações bidirecionais entre areferida instalação central e cada um da referidapluralidade de dispositivos de nó através de associaçõescom respectivos mestres dos referidos mestres de célula.Nessa modalidade de exemplo, preferencialmente cada um dosreferidos dispositivos de nó é configurado para manutençãode uma tabela de vizinho contendo uma informação sobre suasrespectivas relações de vizinho e enlaces de comunicaçõesem uma respectiva célula formada por seu respectivo mestrede célula, para encaminhamento desta tabela de vizinho paraseu respectivo mestre de célula, para atualização de suarespectiva tabela de vizinho quando quaisquer mudançasocorrerem em qualquer uma de suas respectivas relações devizinho ou enlaces de comunicação, e para encaminhamentodessa tabela de vizinho atualizada para seu respectivomestre de célula; e cada respectivo mestre de célula éconfigurado para seletivamente enviar uma mensagem deenlace descendente de difusão para todos os dispositivos denó em seu respectivo mestre de célula, e para o envioseletivo de uma mensagem de enlace descendente demonodifusão para um dispositivo de nó especifico associadoa sua respectiva célula, usando-se um percurso de enlacedescendente de monodifusão determinado por ele com base nastabelas de vizinho recebidas a partir de todos osdispositivos de nó em sua respectiva célula. Com um arranjocomo esse, a rede adapta dinamicamente seu roteamento deenlace descendente a mudanças em enlaces de comunicaçõesdentre os referidos dispositivos de nó da mesma.
Ainda uma outra modalidade de exemplo presente serefere mais particularmente a um dispositivo de metrologiapara uso com uma rede de malha de sistema de mediçãoavançado com roteamento de enlace descendente de modomúltiplo, e incluindo uma instalação central, umapluralidade de dispositivos de nó, com pelo menos algunsdesses dispositivos de nó compreendendo dispositivos demetrologia, e pelo menos alguns desses dispositivos de nócompreendendo mestres de célula, que provêem comunicaçõesentre a referida instalação central e outros dosdispositivos de nó associados a isso nas respectivascélulas formadas pelos respectivos mestres de célula, comcada dispositivo de nó configurado para comunicaçõesbidirecionais com essa instalação central através deassociações com respectivos mestres de célula. Umdispositivo de metrologia de exemplo como essepreferencialmente pode compreender uma porção de metrologiaconfigurada para a medição do consumo de um bem de consumode serviço de utilidade pública; uma porção de transmissorconfigurada para transmitir uma informação de consumo eoutros dados; e uma porção de receptor configurada parareceber uma informação a partir de outros dispositivos derede em uma rede associada. Essas porções de dispositivo demetrologia preferencialmente são configuradas para amanutenção de uma tabela de vizinho contendo uma informaçãosobre suas respectivas relações de vizinho e enlaces decomunicações em uma respectiva célula formada por seurespectivo mestre de célula em uma rede associada, paraencaminhamento de sua tabela de vizinho para seu respectivomestre de célula, para atualização de sua respectiva tabelade vizinho, quando quaisquer mudanças ocorrerem em qualqueruma de suas relações de vizinho ou enlaces de comunicações,e para encaminhamento dessa tabela de vizinho atualizadapara seu respectivo mestre de célula, de modo que essemestre de célula possa seletivamente encaminhar mensagensde enlace descendente para os respectivos dispositivos denó de sua célula para chegarem ao dispositivo de nópretendido.
Um número de exemplo presente se refere a umametodologia para se permitirem notificações de falta em umarede de malha de sistema de medição avançado. Essa presentemetodologia de exemplo pode compreender o estabelecimentode uma rede incluindo uma instalação central e umapluralidade de dispositivos finais, pelo menos algunsdesses dispositivos finais compreendendo dispositivos demetrologia; a configuração da rede para comunicaçõesbidirecionais entre a instalação central e cada um dapluralidade de dispositivos finais; fazer com que umdispositivo final experimentando condições de falta depotência transmita uma mensagem de falta de potência paradispositivos finais vizinhos; e a configuração dapluralidade de dispositivos finais de modo que dispositivosfinais vizinhos não experimentando uma falta de potênciarespondam a uma mensagem de falta de potência paraencaminhamento dessa mensagem de falta de potência para ainstalação central pela rede. Com uma metodologia deexemplo como essa, vantajosamente os dados de falta depotência são reportados para a instalação central atravésda rede usando-se dispositivos finais não experimentandocondições de falta de potência, sem se requerer um enlacede comunicações direto entre a instalação central e umdispositivo final experimentando condições de falta depotência.
O assunto de aparelho presente de exemplo pode serelacionar a uma rede de malha de sistema de mediçãoavançado com uma funcionalidade de notificação de falta depotência. Uma presente rede como essa de exemplo podecompreender uma instalação central; e uma pluralidade dedispositivos finais, pelo menos alguns desses dispositivosfinais compreendendo dispositivos de metrologia, com areferida instalação central e a referida pluralidade dedispositivos finais sendo configuradas para comunicaçõesbidirecionais entre elas. Com um arranjo de exemplo comoesse, a pluralidade de dispositivos finais é configurada demodo que um dispositivo final experimentando condições defalta de potência transmita uma mensagem de falta depotência para dispositivos finais vizinhos. Essapluralidade de dispositivos finais preferencialmente aindaé configurada de modo que os dispositivos finais vizinhosnão experimentando uma falta de potência respondam a umamensagem de falta de potência para encaminhamento dessamensagem de falta de potência para a referida instalaçãocentral pela referida rede. Com um arranjo como esse, osdados de falta de potência são reportados para a referidainstalação central através da referida rede usando-sedispositivos finais não experimentando condições de faltade potência, sem se requerer um enlace de comunicaçõesdireto entre a referida instalação central e um dispositivofinal experimentando condições de falta de potência.
Outras presentes modalidades de exemplo podem serelacionar mais diretamente ao assunto de dispositivovariado, tal como um dispositivo de metrologia com umafuncionalidade de notificação de falta de potência para usocom uma rede de malha de sistema de medição avançado tendouma instalação central e uma pluralidade de outrosdispositivos de rede, pelo menos alguns deles compreendendooutros dispositivos de metrologia. Um dispositivo demetrologia como esse preferencialmente pode compreender umaporção de metrologia configurada para medir o consumo de umbem de consumo de serviço de utilidade pública; uma porçãode transmissor configurada para transmitir uma informaçãode consumo e outros dados; e uma porção de receptorconfigurada para receber uma informação a partir de outrosdispositivos de rede. Preferencialmente, esse dispositivode metrologia é configurado, quando experimentandocondições de falta de potência, para fazer com que areferida porção de metrologia cesse a medição de consumo epara fazer com que a referida porção de transmissortransmita uma mensagem de falta de potência; e essedispositivo de metrologia ainda é configurado, quando nãoexperimentando condições de falta de potência, para fazercom que a referida porção de receptor receba uma mensagemde falta de potência a partir de um outro dispositivo demetrologia, e fazer com que a referida porção detransmissor transmita essa mensagem de falta de potência.
Um método de exemplo como esse pode compreender oestabelecimento de uma rede incluindo uma o estabelecimentode uma rede incluindo um nó de raiz de instalação central euma pluralidade de dispositivos de nó, pelo menos algunsdesses dispositivos de nó compreendendo dispositivos demetrologia; a configuração da rede para comunicaçõesbidirecionais entre o nó de raiz de instalação central ecada um da pluralidade de dispositivos de nó; a computaçãode um atraso de propagação local médio para cada enlace deum salto; a computação do atraso de propagação total aolongo de cada percurso até o nó de raiz de instalaçãocentral; a seleção em cada dispositivo de nó do valor maiscurto de atraso de propagação total para a definição de seupróprio valor de atraso de propagação global; e a conduçãode comunicações usando o percurso correspondente ao valorselecionado. Com um método de exemplo como esse, ascomunicações dentre os nós na rede são otimizadas.
Ainda uma outra presente metodologia de exemplo serefere a um método para a otimização de uma rede de malhade sistema de medição avançado. Essa presente metodologiade exemplo pode compreender o estabelecimento de uma redeincluindo um nó de raiz de instalação central e umapluralidade de dispositivos de nó, pelo menos alguns dessesdispositivos de nó compreendendo dispositivos demetrologia; a configuração da rede para comunicaçõesbidirecionais entre o nó de raiz de instalação central ecada um da pluralidade de dispositivos de nó; a computaçãode um atraso de propagação local médio para cada enlace deum salto; a propagação de uma informação de atraso depropagação global a partir do nó de raiz de instalaçãocentral para cada um dos dispositivos de nó em uma basepasso a passo; o armazenamento da informação de atraso depropagação global em cada dispositivo de nó; e a conduçãode comunicações usando um percurso correspondente ao valormais curto de atraso de propagação total, com base nainformação de atraso de propagação global armazenada e noatraso de propagação local médio. Com uma metodologia comoessa, cada dispositivo de nó pode selecionar um percurso decomunicações com base apenas no conhecimento de seu próprioatraso de propagação local médio e na informação de atrasode propagação global a partir dos dispositivos de nóvizinhos imediatos.
Ainda outras metodologias de exemplo presentes sãoprovidas pela incorporação alternativamente de váriosrecursos presentes. Um exemplo é a inclusão adicional decada nó tornado disponível seu valor de atraso depropagação global pela atualização de seu cabeçalho demensagem. Ainda em outras alternativas, as presentesmetodologias de exemplo podem incluir o atraso depropagação local médio ser derivado pela manutenção de umregistro de todas as tentativas de comunicação com cada umda pluralidade de dispositivos de nó na direção do nó deraiz de instalação central; e a computação de uma taxa desucesso de comunicação estatística para cada um dapluralidade de dispositivos de nó.
Em certas presentes alternativas, o atraso depropagaçã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, Td é otempo necessário para um pacote viajar de um transmissorpara um receptor, P é a taxa de sucesso de pacote, e Tr é otempo de espera entre transmissões. Em certas presentesmetodologias alternativas de exemplo, a taxa de sucesso depacote pode ser atualizada após cada tentativa detransmissão de pacote com uma média deslizante usando arelação:
<formula>formula see original document page 53</formula>
onde P(n) é a taxa de sucesso de pacote para um dadonó n, Nav é o número de transmissões usadas para acomputação da média, e PS(n) é uma indicação de sucesso oufalha em uma tentativa n, onde PS(n) = 0 se uma transmissãoη tiver falhado e PS(η) = 1 se uma transmissão η tiver sidobem sucedida. Nesses métodos alternativos, o atraso depropagação de qualquer enlace pode ser atualizado usando-sea relação:
<formula>formula see original document page 53</formula>
onde Dr (n) é o atraso de propagação de um enlace paratransmissão η e PS (n) é uma indicação de sucesso ou falhaem uma tentativa n, onde PS (n) = 0 se uma transmissão ηtiver falhado, e PS (η) = 1 se uma transmissão η tiver sidobem sucedida.
É para ser entendido que o presente assunto igualmentepertence ao assunto de aparelho correspondente. Umamodalidade de exemplo presente se refere a uma rede demalha de sistema de medição avançado, que compreende um nóde raiz de instalação central; e uma pluralidade dedispositivos de nó. Preferencialmente, nessa modalidade deexemplo, cada dispositivo de nó é configurado paracomunicações bidirecionais com o referido nó de raiz deinstalação central, pelo menos alguns desses dispositivosde nó compreendendo dispositivos de metrologia. Nessamodalidade de exemplo, cada dispositivo de nó éadicionalmente configurado para a computação de um atrasode propagação local médio para cada enlace de um salto parasi mesmo na rede de malha e para selecionar o percurso detransmissão mais curto para o referido nó de raiz deinstalação central, com base apenas em seu próprio atrasode propagação médio computado e em uma informação de atrasode propagação global armazenada em seus vizinhos imediatos.Com um arranjo como esse, as comunicações entre o nó deraiz de instalação central e a referida pluralidade dedispositivos de nó pode ser otimizada.
Uma presente modalidade de exemplo se refere a ummétodo para habilitar um dispositivo final de rede recéminstalado para o estabelecimento de um enlace com uma redede salto de freqüência de sistema de medição avançadoexistente. Um método de exemplo como esse pode compreendero estabelecimento de uma rede incluindo uma instalaçãocentral e uma pluralidade de dispositivos finais, pelomenos alguns desses dispositivos finais compreendendodispositivos de metrologia; a configuração da rede paracomunicações bidirecionais entre a instalação central ecada um da pluralidade de dispositivos finais; fazer comque um dispositivo final recém instalado transmita um sinalde orientação de descoberta, o sinal de orientação dedescoberta incluindo uma informação quanto a um canal deescuta especifico no qual o dispositivo final recéminstalado escutará durante uma janela de escuta; aconfiguração da pluralidade selecionada de dispositivosfinais para a transmissão de uma resposta a um sinal deorientação de descoberta recebido; a colocação dodispositivo final recém instalado em um modo de escutadurante uma janela de escuta no canal de escutaespecificado no sinal de orientação de descobertatransmitido; a configuração do dispositivo final recéminstalado para a coleta e o armazenamento de uma informaçãotransmitida a partir de um ou mais da pluralidade dedispositivos finais em resposta ao sinal de orientação dedescoberta; e a configuração do dispositivo final recéminstalado para sincronização com uma rede preferida, combase em qualquer informação coletada de acordo comcritérios predeterminados.
Outras presentes modalidades de exemplo se referem aum sistema de medição avançado. Um sistema presente deexemplo como esse pode se referir a uma rede de salto defreqüência de sistema de medição avançado, que compreendeuma instalação central e uma pluralidade de dispositivosfinais. Preferencialmente, pelo menos alguns dessesdispositivos finais compreendem dispositivos de metrologia,com a instalação central e essa pluralidade de dispositivosfinais sendo configuradas para comunicações bidirecionaisentre si. Ainda, pelo menos um dispositivo é incluído,configurado para se tentar estabelecer um enlace com pelomenos um dessa pluralidade de dispositivos finais de acordocom critérios predeterminados. Com essa modalidade deexemplo, preferencialmente pelo menos um dessesdispositivos é configurado para tentar o estabelecimento deum enlace pela transmissão de uma pluralidade de sinais deorientação de descoberta em canais de salto sucessivos,cada sinal de orientação incluindo uma informação quanto aum canal específico no qual pelo menos um referidodispositivo escutará durante uma janela de escuta, e quantoao número de sinais de orientação remanescentes a seremtransmitidos.
Uma outra presente modalidade de exemplo se referemais particularmente a um dispositivo de metrologia parauso com uma rede de salto de freqüência de sistema demedição avançado. Um presente dispositivo de exemplo comoesse pode compreender uma porção de metrologia configuradapara medir o consumo de um bem de consumo de serviço deutilidade pública; uma porção de transmissor configuradapara transmitir uma informação de consumo; e uma porção dereceptor configurada para receber uma informação a partirde outros dispositivos de rede. Com um presente dispositivode exemplo como esse, o dispositivo de metrologia éconfigurado para fazer com que a porção de transmissortransmita sinais de orientação de descoberta por várioscanais de salto em sucessão, começando com um canal desalto selecionado randomicamente, cada sinal de orientaçãode descoberta incluindo o número de sinais de orientação dedescoberta remanescentes a serem enviados e o canal no quala porção de receptor escutará uma resposta.
Uma presente modalidade de exemplo se refere a ummétodo para gerenciamento de tamanho de célula em uma redede malha de sistema de medição avançado. Essa metodologiade exemplo preferencialmente pode compreender oestabelecimento de uma rede de malha que inclui pelo menosuma célula incorporando pelo menos um nó mestre e umapluralidade de dispositivos de nó, pelo menos alguns dessesdispositivos de nó compreendendo dispositivos demetrologia, e pelo menos alguns desses dispositivos de nósendo organizados em pelo menos uma célula; a configuraçãoda rede para comunicações bidirecionais dentre pelo menosum nó mestre e cada um da pluralidade de dispositivos de nóusando um hiperquadro de repetição subdividido em umprotocolo de pacote de intervalo de tempo de repetição; asincronização de uma pluralidade dos dispositivos de nópara pelo menos um nó mestre; o estabelecimento de umindicador de tamanho de célula com base no número dedispositivos de nó sincronizados para o nó mestre; oestabelecimento de um atraso de propagação médio global combase no atraso de propagação médio presentemente entre cadadispositivo de nó e o nó mestre; a transmissão do indicadorde tamanho de célula e da informação de atraso depropagação médio global como uma porção de qualquermensagem transmitida a partir do nó mestre; e em cadarespectivo dispositivo de nó, a classificação e a seleçãode vizinhos do mesmo para seleção do melhor acesso parasincronização e para se fazer uma escolha entre célulasdisponíveis diferentes.
Uma outra presente modalidade de exemplo se refere auma rede de malha de sistema de medição avançado. Essamodalidade de exemplo preferencialmente pode compreenderuma rede de malha que inclui pelo menos uma célula queincorpora pelo menos um nó mestre e uma pluralidade dedispositivos de nó, pelo menos alguns desses dispositivosde nó compreendendo dispositivos de metrologia, e pelomenos alguns desses dispositivos de nó sendo organizados empelo menos uma célula, com essa rede de malha configuradapara 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 umprotocolo de pacote de intervalo de tempo de repetição, ecom uma pluralidade de dispositivos de nó sincronizados como nó mestre; e um transmissor, associado ao nó mestre, econfigurado para a transmissão de um indicador de tamanhode célula com base no número de dispositivos de nósincronizados com o nó mestre, e para a transmissão de umatraso de propagação médio global com base no atraso depropagação médio respectivamente entre cada dispositivo denó e o nó mestre, com essas transmissões compreendendo umaporçã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 partirdo referido transmissor, e com base nisso, a classificaçãoe a seleção de vizinhos dos mesmos de modo a se selecionaro melhor acesso para sincronização e de modo a se fazer umaescolha entre células disponíveis diferentes.
Recursos presentes adicionais podem ser praticados, deforma alternativa e/ou adicional com as modalidades deexemplo precedentes, por meio do que as presentesmodalidades adicionais são providas.
Objetivos e vantagens adicionais do presente assuntosão estabelecidos em ou serão evidentes para aqueles deconhecimento comum na técnica a partir da descriçãodetalhada aqui. Também deve ser adicionalmente apreciadoque modificações e variações nos recursos, elementos eetapas especificamente ilustrados, referidos e discutidosdaqui podem ser praticadas em várias modalidades e usos dopresente assunto, sem que se desvie do espírito e do escopodo assunto. As variações podem incluir, mas não estãolimitadas a uma substituição de meios, recursos ou etapasequivalentes por aquelas ilustradas, referenciadas oudiscutidas, e a reversão funcional, operacional ou deposição de várias partes, recursos, etapas ou similares.
Mais ainda, é para ser entendido que modalidadesdiferentes, bem como modalidades presentemente preferidasdiferentes do presente assunto podem incluir váriascombinações ou configurações de recursos, etapas ouelementos presentemente mostrados ou seus equivalentes,incluindo combinações de recursos, partes ou etapas ouconfigurações dos mesmos não expressamente mostradas nasfiguras ou declaradas na descrição detalhada dessasfiguras. Modalidades adicionais do presente assunto nãoexpressadas necessariamente na seção de sumário podemincluir e incorporar várias combinações de aspectos derecursos, componentes ou etapas referenciados nos objetivosresumidos acima e/ou outros recursos, componentes ouetapas, conforme discutido de outra forma neste pedido.Aqueles de conhecimento comum na técnica mais bemapreciarão os recursos e os aspectos dessas modalidades ede outras, mediante uma revisão do restante do relatóriodescritivo.
BREVE DESCRIÇÃO DOS DESENHOS
Uma exposição plena e capacitante do presente assunto,incluindo o melhor modo do mesmo, dirigido a alguém deconhecimento comum na técnica, é estabelecida no relatóriodescritivo, o que faz referência às figuras em apenso, nasquais:
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 dediagrama de blocos de um Sistema de Medição Avançado (AMS)e uma representação de uma metodologia correspondente domesmo, de acordo com o presente assunto;
a FIGURA 3B ilustra um diagrama de blocos de ummedidor de exemplo que incorpora recursos de interface deacordo com o presente assunto;
a FIGURA 3C ilustra um emprego de Sistema de MediçãoAvançado que incorpora vários dos aspectos de aparelho e demetodologia do presente assunto;
a FIGURA 3D ilustra esquematicamente uma metodologiade exemplo e o aparelho correspondente para a transmissãode um firmware para dispositivos finais de acordo com opresente assunto;
a FIGURA 3E ilustra esquematicamente uma metodologiade exemplo e um aparelho correspondente para a transmissãode imagens de firmware diferentes para dispositivos finaisselecionados;
a FIGURA 3F ilustra um diagrama de blocos doscomponentes de um Agente de Coleta de acordo com umamodalidade de exemplo do presente assunto;
a FIGURA 4 descreve o assunto de QUADRO DE ASSUNTOPRESENTE INTEIRO PARA UMA MENSAGEM DE ENLACE ASCENDENTE;
a FIGURA 5 descreve o assunto de BLOCOS DE DADOS PARACODIFICAÇÃO / DECODIFICAÇÃO DE FEC;
a FIGURA 6 descreve o assunto de TABELA DEENTRELAÇAMENTO PARA CODIFICAÇÃO / DECODIFICAÇÃO DE FEC;
a FIGURA 7 descreve o assunto de MDPU APÓSENTRELAÇ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 CAMADAFÍSICA;
a FIGURA 11 descreve o assunto de DIVISÃO DE TEMPO EDE FREQÜÊNCIA;
a FIGURA 12 descreve o assunto de HIPERQUADRO ESEQÜÊNCIA DE CANAL (15 CANAIS, 10 SEQÜÊNCIAS BÁSICAS);
a FIGURA 13 descreve o assunto de ESTRUTURA DEHIPERQUADRO;
a FIGURA 14 descreve o assunto de ELEMENTOS PRIMITIVOSPARA SEQÜÊNCIAS DE SALTO BÁSICAS DE PHY-FHSS-NA-915;
a FIGURA 15 descreve o assunto de MARGENS DE TS ESUBINTERVALOS DE TEMPO;
a FIGURA 16 descreve o assunto de ESTRUTURA DEMANUTENÇÃO DE TEMPO DE PROTOCOLO;
a FIGURA 17 descreve o assunto de FORMATO DE ESTAMPADE TEMPO DE ITP PADRÃO;
a FIGURA 18 descreve o assunto de SINCRONIZAÇÃO ENÍVEIS;
a FIGURA 19 descreve o assunto de SINCRONIZAÇÃOHIERÁRQUICA;
a FIGURA 2 0 descreve o assunto de RESSINCRONIZAÇÃOENTRE PONTOS FINAIS;
a FIGURA 21A descreve pais de SYNC potenciais e paissaudáveis para um assunto de nó sincronizado;
a FIGURA 21B descreve o assunto de Grau deConectividade;
a FIGURA 22 descreve o assunto de EXEMPLO DEDESCOBERTA DE FASE COM NÚMERO DE SEQÜÊNCIA DE SALTO DEFREQÜÊNCIA BÁSICO 0 DE 915;
a FIGURA 23 descreve uma Tabela relativa a exemplos doassunto de vizinhos preferidos;
a FIGURA 24 descreve o assunto de EXEMPLO DECONFIGURAÇÃO;
a FIGURA 2 5 descreve o assunto de EXEMPLO DE PROCESSODE SINCRONIZAÇÃO;
as FIGURAS 26A e 26B descrevem respectivamente umexemplo de uma Configuração Inicial e um exemplo de um novoponto final, ilustrativos de circunstâncias de um pontofinal descobrindo um melhor ponto final para fins decomunicação, pelo presente assunto;
a FIGURA 2 7 descreve um assunto de RESSINCRONIZAÇÕES ECORREÇÕES DE DERIVA DE CRISTAL NO TEMPO;
a FIGURA 28 descreve o assunto de ALGORITMO DECOMPENSAÇÃO DE DERIVA DE RELÓGIO LOCAL;
a FIGURA 2 9 descreve o assunto de FILTRO DE PASSABAIXA PARA CORREÇÃO DE DERIVA DE RELÓGIO;
a FIGURA 3OA descreve o assunto de Gerenciamento deTabela de Vizinho;
a FIGURA 3OB descreve o assunto de IMPLEMENTAÇÃO DECRC3 2 TÍPICA;
a FIGURA 31 descreve o assunto de MONITORAÇÃO DE CARGADE TRÁFEGO: O NÓ B ESTÁ OUVINDO A(S) MENSAGEM (NS) DE (N)ACKA PARTIR DE SEUS PAIS A E C;
a FIGURA 32 descreve o assunto de protocolo presentede 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 DERSSI;
a FIGURA 35 descreve o assunto de QUADRO DE MAC;a FIGURA 36 descreve o assunto de TIPO DE QUADRO DEMAC;
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 - SYNCNACK;
a FIGURA 40 descreve o assunto de SYNC ACK;
a FIGURA 41 descreve o assunto de SINAL DE ORIENTAÇÃODE REQUISIÇÃO;
a FIGURA 42 descreve o assunto de DADOS DEMONODIFUSÃO;
a FIGURA 43 descreve o assunto de DADOS DEMULTIDIFUSÃO;
a FIGURA 44 descreve o assunto de ITP;
a FIGURA 45 descreve o assunto de SINAL DE ORIENTAÇÃODE DESCOBERTA;a FIGURA 4 6 descreve o assunto de FALTA;
a FIGURA 4 7 descreve o assunto de SERVIÇOS DE CAMADADE MAC;
a FIGURA 4 8 descreve o assunto de DIAGRAMA DE ESTADOSEM GERAL;
a FIGURA 4 9 descreve o assunto de VALORES PADRÕES DEPARÂMETRO DE LLC;
a FIGURA 5 0 descreve o assunto de RETORNO APÓS COLISÃOEXPONENCIAL BINÁRIO TRUNCADO ATRASADO PARA NOVAS TENTATIVASDE TRANSMISSÃO SE PACOTES NÃO FOREM RECONHECIDOS;
a FIGURA 51 descreve o assunto de RETORNO APÓS COLISÃOEXPONENCIAL BINÁRIO TRUNCADO PARA NOVAS TENTATIVAS DETRANSMISSÃO SE PACOTES FOREM RECONHECIDOS NEGATIVAMENTE;
a FIGURA 52 descreve o assunto de TABELA DE DUPLICAÇÃODE LLC;
a FIGURA 53 descreve o assunto de QUADRO DE LLC;
a FIGURA 54 descreve o assunto de SERVIÇOS DE CAMADADE LLC;
a FIGURA 55 descreve o assunto de VALORES PADRÕES DEPARÂMETRO DE CAMADA DE NET;
a FIGURA 5 6 descreve o assunto de TABELA DE DUPLICAÇÃODE NET;
a FIGURA 57A descreve o assunto de Topologia para umexemplo de roteamento de enlace descendente;
a FIGURA 57B descreve o assunto de Tabela deRoteamento de CR para um exemplo de roteamento de enlacedescendente;
a FIGURA 57C descreve o assunto de Indicador detamanho de célula (% de NET_Max_Nb_of_EPs);
a FIGURA 57D descreve o assunto de ações de mestre decélula quando a camada de eletrodo está cheia ou o nó nãoem tabela de roteamento;
a FIGURA 58 descreve o assunto de QUADRO DE NET;
a FIGURA 5 9 descreve o assunto de TIPO DE QUADRO DENET;
a FIGURA 6 0 descreve o assunto de QUADRO DE ENLACEASCENDENTE;
a FIGURA 61 descreve o assunto de QUADRO DE ENLACEDESCENDENTE;
a FIGURA 62 descreve o assunto de LISTA DE VIZINHO;
a FIGURA 6 3 descreve o assunto de ENLACE ASCENDENTECOM QUADRO DE LISTA DE VIZINHO;
a FIGURA 64 descreve o assunto de DIFUSÃO;
a FIGURA 65 descreve o assunto de NOTIFICAÇÃO DECÉLULA FORA;
a FIGURA 6 6 descreve o assunto de ENLACE ROMPIDO;
a FIGURA 67 descreve o assunto de FALTA;
a FIGURA 6 8 descreve o assunto de NOTIFICAÇÃO DE SAÍDADE CÉLULA;
a FIGURA 6 9 descreve o assunto de SERVIÇOS DE CAMADADE REDE;
a FIGURA 7 0 descreve o assunto de MODELO DE LAÇO DERETORNO DE COMPENSAÇÃO DE DERIVA DE CRISTAL;
a FIGURA 71 descreve uma versão simplificada doassunto de MODELO DE LAÇO DE RETORNO DE COMPENSAÇÃO DEDERIVA DE CRISTAL, conforme representado na FIGURA 70;
a FIGURA 72 descreve o assunto de RESPOSTA DE DEGRAUDE CORREÇÃO DE DERIVA DE CRISTAL;
as FIGURAS 73A, 73B e 73C, respectivamente, ilustramaspectos 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 DEFALHA DE TRANSMISSÃO;
a FIGURA 7 5 descreve o assunto de MODELO PARA A CARGADE TRÁFEGO NO RELÊ DE CÉLULA;
a FIGURA 76 descreve o assunto de RITMO DETRANSFERÊNCIA DE DADOS, T(Β,A,A) E PSR (COM RECONHECIMENTO)VERSUS DENSIDADE DE ENTRADA DE TRÁFEGO, R(Β,A,A) PARA PSRE0,8;
a FIGURA 7 7 descreve o assunto de RITMO DE
TRANSFERÊNCIA DE DADOS, T(Β,A,A) VERSUS PSRE;a FIGURA 78 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 OSPACOTES PODERIAM SER PERDIDOS.
0 uso repetido de caracteres de referência por todo opresente 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 baseiaem abreviações e acrônimos tendo os significadospretendidos, conforme estabelecido na Tabela de Definiçõesem apenso, a qual faz parte da presente exposição.
Um modelo de referência para interconexão de sistemasabertos (referida como OSI - Interconexão de SistemasAbertos) foi descrita pela ISO (a Organização Internacionalpara Padronização). Esse modelo, representado pela presenteFigura 1, é uma decomposição funcional de um sistema decomunicação. Em outras palavras, as camadas diferentesrealizam funções diferentes. Uma camada N oferece serviçospara a camada acima N+l, pela melhoria dos serviçosoferecidos a esta camada N pela camada subjacente N-I. Essaarquitetura permite modificações adicionais em uma camadasem a mudança das outras. Mais ainda, permite umacompatibilidade entre diferentes períodos de tempo com baseno mesmo princípio.
As combinações selecionadas de aspectos da tecnologiamostrada correspondem a uma pluralidade de modalidadesdiferentes do presente assunto. Deve ser notado que cadauma das modalidades de exemplo apresentadas e discutidasaqui não deve insinuar limitações do presente assunto.Recursos ou etapas ilustradas ou descritas como parte deuma modalidade podem ser usados em combinação com aspectosde uma outra modalidade para a produção ainda de outrasmodalidades. Adicionalmente, certos recursos podem serintercambiados com dispositivos ou recursos similares nãoexpressamente mencionados, os quais realizam a mesma funçãoou uma similar.
O presente assunto de rede e arquitetura de protocolopode ser descrito com base em uma árvore de quatro tipos deelementos, espalhados em células, representados pela Figura2A. No topo dessa arquitetura está um agente de coleta, oqual atua como um banco de dados central. Ele conhece todasas células e seus conteúdos, isto é, a célula em que cadamedidor está e seu endereço. Ele também coleta dadosmensalmente para todo ponto final e permite acesso aqualquer medidor na rede. 0 usuário pode requisitar ouenviar dados para um único medidor ou uma informação dedifusão. O agente de coleta pode se comunicar com oroteador da célula selecionada por um protocolo de TCP/IPdentro da rede Internet.
Nessa hierarquia de árvore, imediatamente abaixo doagente de coleta ficam os roteadores das células, referidoscomo relês de célula. Há um relê de célula para cada célulae é o gateway entre medidores individuais na célula e oagente de coleta. 0 relê de célula contém uma tabela deroteamento de todos os medidores em sua célula. Ele tambémpode encaminhar dados nas duas direções, isto é, entre oagente de coleta e os pontos finais. Ele também assume opapel de sincronização da célula.
No fundo dessa árvore estão localizados os assimdenominados pontos finais (EPs). Eles podem transmitir ereceber uma informação de medição. Além disso, cada umdeles pode atuar como um relê para pontos finais distantessem um hardware adicional.
O último módulo indicado desses quatro tipos deelementos é a unidade de Walk-by (para ser percorrida a pépara se fazer a leitura do medidor), um portátil de ZigBeeque pode se comunicar com órfãos ou configurar osparâmetros de protocolo em questão. Este módulo em si nãocontém o protocolo em questão. Ele usa a parte de ZigBee doregistrador para comunicação com ele.
Portanto, a rede em questão usa 3 meios, os quais sãoo enlace de RF em questão, um enlace de RF de Zigbee, e umenlace de TCP/IP, tudo conforme representado pela presenteFigura 2A.
A presente Figura 2B representa em parte o protocoloem questão, o qual em parte é baseado nas 3 primeirascamadas do modelo de camadas em questão, respectivamenterotuladas como: Física, Enlace de Dados e Camada de Rede.
Essa camada de enlace de dados ainda é dividida em 2subcamadas, MAC (controle de acesso a meio) e LLC (controlede enlace lógico). Conforme representado, cada camada podese comunicar por meio do SAP (Ponto de acesso de serviço)com camadas imediatamente abaixo e imediatamente acima. AFigura 2B representa o modelo de camada de um EP (pontofinal) 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 omedidor em si para troca de dados de medição ou com oaplicativo de relê de célula. A pilha à esquerda representao mestre de célula, enquanto aquela à direita é a seção deWAN de relê de célula (ou placa de relê de célula).
A discussão a seguir descreve cada camada da presenteFigura 2B, incluindo suas respectivas funcionalidades e osserviços.
A interface de camada de aplicativo (API) não faz emsi parte do protocolo em questão, mas de um ponto de vistade rede é a camada imediatamente acima. Uma meta principaldo presente assunto é transportar dados a partir da camadade API. Em uma modalidade de exemplo, na rede de AMI acamada de API poderia seguir o protocolo C12.22, conformediscutido por toda a presente exposição. Contudo, é paraser entendido que o presente assunto também poderiafuncionar com uma outra camada de API.
A camada de rede é a camada mais alta do presenteassunto de protocolo. Ela está encarregada do roteamento depacotes para seu destino final. Para ser capaz de fazerisso, ela gerencia uma tabela de seus vizinhos a um saltoobtida através da camada de MAC. Para uma mensagem deenlace ascendente (em direção ao relê de célula (CR)) , estatabela permite que a camada de rede envie a mensagem para omelhor vizinho a um salto de nível mais baixo. A camada deNET 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 decélula) preferencialmente é uma exceção, uma vez que ela éaquela que pode enviar uma mensagem para qualquer pontofinal (EP) na célula; é possível porque a CR NET tem todasas tabelas de vizinho (ou pais) da célula e, assim, é capazde enviar uma mensagem com todos os endereços (o percursointeiro) no cabeçalho. A camada CR (ou CM) NET também podeenviar uma mensagem de difusão para todos os EPs na célula.Para isto, cada camada de NET envia esta mensagem paratodos os seus filhos.
A camada de controle de enlace lógico (LLC) estáprincipalmente encarregada da repetição de mensagens quenão foram ouvidas (incluindo no caso de difusão) e defragmentação de mensagens que são longas demais. Ela tambémfiltra mensagens duplicadas em ambas as direções, para nãosobrecarregar a camada de NET ou o enlace de RF.Finalmente, freqüentemente é usada apenas como um enlaceentre as camadas de NET e MAC.
A camada de controle de acesso a meio (MAC) lida com omaior número de tarefas ou funções. Em primeiro lugar, acamada de MAC é o gerenciador de sincronização. Quando apotência é ligada, ela tenta encontrar uma célula e, umavez conectada a ela, ajusta seu nível para ficar em contatocom o melhor pai possível.
É para ser entendido por aqueles de conhecimento comumna técnica que vários termos podem ser usados para adescrição de certas relações funcionais. Por exemplo, ostermos pai ou pais podem ser usados de forma intercambiávelem relação aos termos filho ou crianças. A escolha dessestermos aqui não tem por significado portar quaisquerlimitações em particular ou um significado além do contextono qual eles são apresentados, conforme será entendido poraqueles de conhecimento comum na técnica.
Dentre as camadas do protocolo em questão, a camada deMAC é a única a ter uma noção de tempo. 0 tempo deprotocolo em questão é dividido em intervalos de tempo (TS)e a camada de MAC os alinha com aqueles de seus pais, osquais fazem o mesmo até uma operação do relê de célula (oque é a referência de tempo na rede). Essa sincronização éfeita através de uma informação de tempo incluída pelascamadas de MAC no cabeçalho de todos os pacotes. Se nãohouver um tráfego, a camada de MAC enviará sinais deorientação de modo que seus filhos possam ficarsincronizados com ela.
Uma outra tarefa da camada de MAC é reconhecer asmensagens recebidas. Um reconhecimento positivo ou negativoé possível (ACK ou NACK) . Estes são reconhecimento de umsalto. Contudo, se a camada de API precisar de umreconhecimento de ponta a ponta, ela precisará inserir arequisição na mensagem que enviar. A camada de MAC tambéminsere vários parâmetros pessoais no cabeçalho de todas asmensagens que envia. Quando recebendo pacotes de seusvizinhos, ela extrai estes parâmetros e gerencia uma tabelade sua vizinhança. Parte desta tabela é comunicada para acamada de NET.
Finalmente, a camada de MAC computa uma CRC(verificação de redundância cíclica) no pacote e a adicionano fim, antes de proporcioná-la para a camada PHY paratransmissão ou a usa quando da recepção de uma mensagempara detecção de erro.
A camada física (PHY) está encarregada da transmissãode dados no enlace de RF. Por padrão ela está sempre nomodo de recepção e nunca decide por si se é paratransmitir. Todas as suas instruções, incluindo pacotes aenviar, vêm da camada de MAC. Antes da transmissão de umpacote, ela computa e adiciona um FEC e, então, adiciona umpreâmbulo e um cabeçalho a este pacote protegido. Quandorecebe um pacote, ela remove estas duas adições, antes deenviar os dados para a camada de MAC. A camada físicatambém provê a potência de pacote recebido (RSSI) e o tempode recepção para a camada de MAC. Como um último serviço,ela também pode medir e proporcionar o valor de RSSI nocanal de escuta atual.
As Figuras 3A a 3C presentes são concernidas, maisparticularmente, a um aparelho de exemplo e a umametodologia para a provisão de uma interface entre ummedidor e um sistema de medição avançado e um aplicativorodando em um sistema como esse, desse modo se permitindouma compatibilidade de plug-n-play (isto é, umaintercambialidade) de dispositivos de metrologia naestrutura operacional aberta em questão, tal como paramedidores C12.22 de padrão ANSI, discutidos em outro lugaraqui. Também, as Figuras 3D a 3F presentes se referem aaparelhos e metodologias de exemplo para a transferência(via download) de um firmware através de uma rede, conformediscutido aqui para dispositivos finais incluindo medidoresde serviço de utilidade pública e relês, tal como para aatualização de um firmware em medidores de receitapreviamente instalados em comunicação e/ou relações decélula / nó por protocolo, conforme descrito em outro lugaraqui. Uma metodologia de propagação viral é mostrada comouma alternativa pelo menos para porções da metodologia dedifusão. Vários desses recursos podem envolver atransferência (via download) de um firmware em uma rede demalha de RF que é disposta em camadas hierárquicas ou umarranjo configurado em "árvore", conforme discutido deoutra forma aqui.
A Figura 3A é uma ilustração de visão geral dediagrama de blocos de um sistema de medição avançado (AMS)de acordo com o presente assunto. 0 sistema de mediçãoavançado (AMS) 100 de acordo com o presente assunto éprojetado para ser um sistema compreensivo para a provisãode uma informação de medição avançada e aplicativos paraserviços de utilidade pública. 0 AMS 100 em uma partepertinente é projetado e construído em torno de protocolospadrões de indústria e transportes e, portanto, épretendido para funcionar com componentes em conformidadecom normas de terceiros.
Os principais componentes do AMS 100 incluem osrespectivos medidores de exemplo 142, 144, 146, 148, 152,154, 156 e 158; uma ou mais respectivas redes baseadas emrádio incluindo uma rede de área de vizinhança de RF (RFNAN) 162 e seu relê de rádio associado 172, e uma rede deárea de vizinhança de comunicações de linha de energia (PLCNAN) 164 e seu relê de PLC associado 174; um backhaulpúblico baseado em IP (protocolo de internet) 18 0; e umagente de coleta 190. Outros componentes no AMS 100 deexemplo incluem uma LAN (rede de área local) de serviço deutilidade pública 192 e um firewall 194 através do qualsinais de comunicações para e do agente de coleta 190 podemser transportados a partir de e para seus respectivosmedidores de exemplo 142, 144, 146, 148, 152, 154, 156 e158 ou outros dispositivos incluindo, mas não limitando, orelê de rádio 172 e o relê de PLC 174.
O AMS 100 é configurado para ser transparente em umcontexto de transporte, de modo que os respectivosmedidores de exemplo 142, 144, 146, 148, 152, 154, 156 e158 possam ser interrogados usando-se o agente de coleta190, independentemente de que infra-estrutura de redeexistir entre eles ou dentre esses componentes. Mais ainda,devido a essa transparência, os medidores também podemresponder ao agente de coleta 190 da mesma maneira.
Conforme representado pela ilustração na Figura 3A, oagente de coleta 190 é capaz de integrar medidoresconectados de rádio, PLC e IP. Para facilitação dessatransparência, o AMS 10 0 opera e/ou tem uma interface com oprotocolo de comunicação de medidor C12.22 de padrão ANSIpara redes. 0 C12.22 é um protocolo transparente de rede, oqual permite comunicações através de substratos de rededíspares e assimétricos. 0 C12.22 detalha todos os aspectosde comunicações, permitindo que medidores em conformidadecom 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 erestauração. Todos os dados fluindo através do sistema sãoenviados na forma de tabelas C12.19. O sistema prove umenvio de mensagem de duas vias pleno para todo dispositivo;contudo, muitas de suas funções podem ser providas atravésde envio de mensagem de difusão ou de multidifusão ecomunicações sem sessão.
Com referência presente à Figura 3B, é ilustrado umdiagrama de blocos de um medidor 200 de exemplo queincorpora os recursos de interface de acordo com o presenteassunto. O medidor 200 preferencialmente incorpora várioscomponentes, incluindo a metrologia 210, uma placa deregistrador 220 e um ou mais dispositivos de comunicações.Na configuração de exemplo presentemente ilustrada, omedidor 200 pode incluir tal como uma interface de RF LAN230 e uma antena associada 232, e uma interface de ZigBee240 e sua antena associada 242. Além disso, um slotopcional 25 0 pode ser provido para a acomodação de uma redede terceiros ou de um módulo de comunicações 252.
A metrologia 210 pode corresponder a um dispositivo deestado sólido configurado para prover (internamente emrelação ao medidor) uma placa de registrador decomunicações de expressão súbita (blurt) C12.18 220. Ascomunicações com o medidor 200 são conduzidas através daespecificação de protocolo estendido C12.22 para mensagensde medição eletrônica (EPSEM). A placa de registrador demedidor 220 é configurada para suportar plenamente astabelas C12.19 e as extensões de C12.22. Embora todos osdados de medidor sejam acessíveis através das tabelaspadronizadas de C12.19, de modo a se facilitaremcomunicações de largura de banda muito baixa, as tabelas defabricante ou os procedimentos armazenados são incluídos,os quais provêem acesso a fatias delimitadas no tempo dedados, tal como o valor de último dia do calendário dedados de intervalo ou outros "agrupamentos" personalizadosde dados.
O medidor 200 pode ser configurado variadamente para aprovisão de capacidades de comunicações diferentes. Nasconfigurações de exemplo, um ou mais dentre módulos decomunicações de GPRS, Ethernet e RF LAN podem ser providos.
O GPRS permitirá que os medidores sejam endereçáveis por IPpor um backhaul público e proverá mais largura de banda doque o medidor provavelmente jamais requererá, mas podeincorrer em custos de assinatura progressivos. Umaconectividade de Ethernet pode ser usada para a construçãode uma ligação com tecnologias de terceiros, incluindoWiFi, WiMax, gateways domésticos e BPL (banda larga porlinhas de energia), sem integração de qualquer uma destastecnologias diretamente no dispositivo de medição, mas coma transigência de requerer uma fiação externa e uma soluçãoem duas partes. Os dispositivos de Ethernet podem serusados primariamente em pilotos e outras aplicaçõesespeciais, e eles adicionalmente podem ser ideais paracertos ambientes intolerantes a RF de alta densidade, taiscomo armários de medidor.
Devido à complexidade aumentada no gerenciamento deuma interface de WAN, com suas exigências de negociação deenlace mais sofisticadas e pilha de TCP/IP (protocolo decontrole de transmissão / protocolo de internet), osmedidores conectados por WAN podem incluir uma placa decircuito adicional dedicada a uma conectividade de WAN.Essa placa, caso usada, preferencialmente teria umainterface com o medidor 200 usando mensagens de EPSEM e oslot opcional 250.
A disponibilidade do slot opcional 250 no medidor 200provê a vantagem de tornar o medidor 200 disponível paraintegração com backhauls de terceiros, tal como PLC(comunicações por linha de energia) . De modo que essesdispositivos de terceiros sejam integrados no AMS 100, poroutro lado, os dispositivos de terceiros precisarão incluiruma placa de comunicações e um relê em conformidade comC12.22 para acoplamento de sinais de comunicações a partirde qualquer rede proprietária de terceiros a uma conexão deIP. Alternativamente, os terceiros poderiam integrar omedidor 2 00 em sua própria solução de ponta a ponta.
O protocolo de comunicações entre o medidor 200 e osrespectivos módulos de comunicações 23 0, 24 0 e o módulo deWAN ou o módulo de comunicações de terceiros opcional 250,seguem os padrões de C12.22, permitindo que quaisquerterceiros projetem conforme o padrão e tenham garantida umaintegração relativamente direta.
A comunicação com o agente de coleta 190 é realizadapor uma conexão de protocolo de Internet. A rede de áreaampla é uma rede de IP plenamente roteável, endereçável quepode envolver uma variedade de tecnologias diferentes,incluindo, mas não limitando, GPRS, WiFi, WiMax, fibra,Ethernet privada, BPL, ou qualquer outra conexão comlargura de banda suficientemente alta e capacidade desuportar uma comunicação por IP de duas vias plena. Váriashipóteses (isto é, critérios do presente assunto) podem serfeitas com referência à IP WAN. O agente de coleta 190preferencialmente é implementado de modo a ser capaz de secomunicar diretamente com outros respectivos nós na IP WAN.Embora as comunicações possam ser conduzidas através de umfirewall 194, não é necessário que elas sejam através de umproxy, a menos que o proxy seja em si um nó de C12.22funcionando como um relê entre uma rede de IP privada e aIP WAN pública.
Ainda de acordo com o presente assunto, a interfaceentre medidores e o gerenciador de aplicativos (gerenciadorde IMA) provido pela presente tecnologia facilitacomunicações entre os dispositivos de nível superiorincluindo, mas não limitando, o agente de coleta 190 evários respectivos medidores e outros dispositivos no AMS100. Mais particularmente, o Gerenciador de IMA usa umgerenciador de C12.22 para a criação de uma especificaçãode protocolo estendido para um objeto de mensagem demedidores eletrônicos (EPSEM) envolvido em um objeto deelemento de serviço de controle de aplicativo (ACSE), parao envio da mensagem para uma rede nativa, para recebimentode uma resposta a partir da rede nativa, e retornar umobjeto de ACSE com a resposta de EPSEM embutida. OGerenciador de IMA preferencialmente então utilizaria o IMApara a classe de dispositivo, de modo a se construir umamensagem de EPSEM a ser enviada para os medidores.
O Gerenciador de IMA fundirá a mensagem de EPSEM comquaisquer ApTitles necessários para a formação de umamensagem de ACSE e, então, passará a mensagem de ACSE paraos medidores apropriados. Uma resposta a partir de ummedidor será recebida a partir da rede no gerenciador deC12.22, o qual analisará gramaticalmente a mensagem de ACSEde modo a extrair o ApTitle e a mensagem de EPSEM. Porúltimo, o gerenciador de C12.22 recebe uma resposta apartir de uma mensagem de ACSE prévia, analisagramaticalmente a resposta de ACSE e a envia para oGerenciador de IMA.
O Gerenciador de IMA processa uma resposta de exceçãoe a submete a um gerenciador de exceção, o qual entrega aexceção para todos os sistemas que tenham assinado aqueletipo de exceção. 0 Gerenciador de IMA utiliza umarmazenamento de metadados para a recuperação de qualquerinformação sobre o ApTitle chamando, tais como classe dedispositivo 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 deexceção qual respectivo medidor experimentou uma falta. 0gerenciador de exceção obtém uma lista de assinantes para otipo de exceção suprido a partir da API de armazenamento demetadados e, então, envia a mensagem para todo sistema denotificação que tenha assinado as notificações do tipo deexceção.
O sistema de medição avançado da presente tecnologiaprove uma série (ou pluralidade) de serviços(funcionalidades) para serviços de utilidade pública. Emsua implementação mais básica, ele prove alimentaçõesdiárias de dados de intervalo residencial ou TOU (tempo deuso). Além dessa funcionalidade, ele provê notificações defalta e restauração de potência, leituras sob demanda,atualizações de firmware, controle de carga / resposta dedemanda, leituras de medidor de gás e mensagens de exibiçãodomésticas. Todas essas funções (serviços) são comunicadosatravés do protocolo de C12.22. De modo a se otimizar o usoda RF LAN de largura de banda baixa, operações selecionadasassumem o uso de procedimentos de fabricante no medidor;contudo, o agente de comunicação de C12.22 geral do sistemanão é especifico para quaisquer tabelas, dispositivos oufabricantes em particular. No futuro, de acordo com opresente assunto, conforme substratos de rede alternativosse tornarem disponíveis, a RF LAN pode ser muito facilmentetrocada por outras tecnologias.
Com a presente referência à Figura 3C, será visto queum emprego de exemplo de sistema de medição avançado deexemplo (AMS) geralmente 300 foi ilustrado. A Figura 3Cilustra para fins de exemplo apenas uma única célula de RFLAN, com doze respectivos nós membros organizados em trêsníveis, bem como quatro medidores de IP conectadosdiretamente 370, 372, 374, e 376. Nesse sistema, todos osrespectivos 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 390têm endereços de rede de C12.22. O agente de coleta 390pode ter de acordo com o presente assunto múltiplosendereços de C12.22 para se permitir um endereçamento emseparado entre diferentes serviços (funcionalidades). 0sistema de gerenciamento de dados de medidor (ou mestres)391 não faz parte da rede de C12.22, mas, preferencialmenteserá implementado de modo a se comunicar pela LAN deserviço de utilidade pública 392 para o agente de coleta390 através de serviços da web. A comunicação entre o relêde célula 302 e a LAN de serviço de utilidade pública 392variadamente envolve o backhaul público 390 e firewall 394,de uma maneira análoga àquela discutida acima em conjuntocom o backhaul público 180 e o firewall 194 (Figura 3A) ,assim como entendido por aqueles de conhecimento comum natécnica.
O processo de aquisição de dados de medidor começa como 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 oagente de coleta 3 90 e pode ser realizada sem conhecimentoda funcionalidade configurada do dispositivo final. Oagente de coleta 3 90 analisa a requisição por dados, eformula uma série de requisições de dados de multidifusão(ou difusão) de C12.22. Essas requisições então sãoenviadas diretamente para o dispositivo (no caso de ummedidor conectado por IP, tal como 370) ou para o relê decélula 3 02 que retransmite a mensagem para fora para todosos nós apropriados. As mensagens de difusão e multidifusãosão enviadas pelo relê de célula 3 02 para todos os membrosda célula, através de uma difusão de nivel de RF LAN deAMS, ou pelo relê de célula repetindo a mensagem. Em nomeda eficiência, o uso de uma difusão de nivel de RF LAN podeser preferido.
Tipicamente, estas requisições são enviadas como umachamada para um procedimento armazenado de fabricante. EmC12.22, as chamadas de procedimento armazenadas sãorealizadas como escritas em uma tabela predeterminada, porexemplo, a "tabela 7" . 0 procedimento armazenado enviará atransferência (via upload) padrão para esse dispositivo.
Por exemplo, um dado medidor pode ser configurado paratransferir (via upload) dois canais de dados de intervalohorário, mais seu histórico de evento. Um outro medidorpoderia ser programado para enviar seus registradores deTOU. 0 procedimento armazenado requererá quatro parâmetrospara ser plenamente operativo de acordo com o presenteassunto: horário de começo de dados, horário de fim dedados, horário de começo de resposta e horário de fim deresposta. Os horários de começo e de fim de dados sãousados para a seleção de quais dados enviar. 0 horário decomeço e o horário de fim de resposta são usados para sedeterminar a janela dentro da qual o sistema à frenteespera receber os dados. Os vários medidores habilitados deAMS da Figura 3C preferencialmente são programáveis nocampo, através de tabelas de C12.22, quanto aos dados detipo a serem incluídos em uma transferência (via upload)padrão.
Quando os dados são enviados para o agente de coleta390, eles são enviados como uma auto-escrita de tabela deC12.19 com o bit de notificação regulado e o bit de nãoresponder regulado. O resultado é que pelo presente assuntonenhum reconhecimento de C12.22 é enviado em resposta àdifusão de agente de coleta, nem o agente de coleta 390 emresposta à notificação - escrita envia qualquer resposta;contudo, a notificação - escrita efetivamente serve pelopresente assunto como um reconhecimento para o recebimentoda difusão.
A seção de processamento de resposta pode usar osdados configurados sobre um dispositivo final e a mensagemde resposta a partir do dispositivo final para adeterminação dos resultados a partir do dispositivo. Aseção de processamento de resposta começa uma operaçãoassociada a um serviço específico em uma lista de tarefa,mas pode ser comutada entre qualquer serviço ativo queesteja esperando uma resposta. Essa operação permite querespostas que contenham registros de eventos do dispositivosejam analisadas gramaticalmente por cada serviço quepoderia estar esperando por uma ação para ser completado nodispositivo final. Isso também permitiria que mensagens nãosolicitadas fossem analisadas gramaticalmente pelo códigode IMA e, então, associadas mais tarde a quaisquer serviçospossíveis, conforme determinado pelo IMA, tudo de acordocom o presente assunto.
Embora a maioria das operações não requeira isso, osmedidores de AMS suportarão um encadeamento de uma série demensagens de EPSEM, tais como múltiplas leituras e escritasde tabela em uma única requisição. Isto é umafuncionalidade que é requerida na especificação de C12.22,e ajudará na melhoria da eficiência do sistema, já queevita o tempo de processamento de envio de uma mensagem emseparado para cada comando de EPSEM. Os dispositivoshabilitados para AMS processarão cada requisiçãoseqüencialmente, permitindo que uma série de operações sejamanipulada em um único comando, cada uma fundamentada napróxima, de modo que uma leitura subseqüente a uma escritareflita os resultados da escrita de requisição. Se umcomando em uma cadeia de EPSEM não puder ser completado, oscomandos remanescentes na cadeia serão rejeitados commensagens de erro apropriadas, pelo presente assunto.
Quando um respectivo dispositivo recebe umarequisição, ele avalia o endereço de multidifusãoespecificado. Se o dispositivo for um membro do grupo demultidifusão, ele responderá à requisição; caso contrário,ele a descartará. A afiliação em diferentes grupos demultidifusão é determinada através do uso da tabela depadrão C12.22 122.
Uma leitura sob demanda pelo presente assunto ésimilar ao processo de aquisição de dados de medidordiariamente; contudo, ao invés de se enviar uma requisiçãode difusão ou multidifusão, o processo de leitura sobdemanda de acordo com o presente assunto se comunicadiretamente com os respectivos medidores desejados. Esseprocesso começa com um usuário iniciando uma leitura sobdemanda através de uma interface de usuário de AMS, ouatravés de uma chamada de serviços da web a partir de umsistema à frente. Pelo presente assunto, uma camada deorquestração do agente de coleta 390 começa pela avaliaçãoda carga de sistema atual do substrato de comunicaçõesatravés do que o respectivo dispositivo é conectado. Asrequisições para uma leitura sob demanda de uma célulasaturada podem ser rejeitadas.
Uma vez que o agente de coleta 3 90 determine que arequisição pode ser honrada, ele seleciona pelo presenteassunto um servidor de comunicação apropriado no agente decoleta, e submete o comando para a recuperação de dados apartir do dispositivo e o retorna. O servidor decomunicações forma uma requisição de leitura de tabela deC12.22 e a envia para o dispositivo diretamente, seconectado por IP, ou para o relê de célula 302 paradispositivos conectados por RF LAN. Em casos em que otráfego flui através da RF LAN, o software de relê decélula recupera a mensagem a partir do backhaul de IP 380,e avalia a mensagem. 0 endereço de destino (em terminologiade C12.22, o denominado ApTitle) pode ser retirado para sepoupar largura de banda na rede, baseando-se, ao invésdisso, no esquema de endereço de RF LAN subjacente paraentrega da mensagem. O software de relê de célula tambémdeve examinar se o ApTitle de destino ainda é válido nacélula. Se o ApTitle de destino não for mais válido, o relêde célula rejeitará a mensagem, retornando um pacote deerro para o agente de coleta. Desde que o destino aindaseja válido, o software de relê de célula enviará amensagem para o dispositivo através da RF LAN, pelopresente assunto.
Uma pilha de protocolo para a RF LAN vantajosamentetoma a mensagem e constrói um percurso de nó para amensagem a tirar, antes de realmente transmitir o pacote.Esse percurso de nó pré-construído permite que o relê decélula 3 02 pelo presente assunto empurre para baixo umamensagem através da árvore da célula, sem a criação demensagens de rádio redundantes. Se o agente de coleta 390quiser fazer uma leitura sob demanda no medidor 356, elecomeçará pelo envio da mensagem para o relê de célula 302.O relê de célula 3 02 por sua vez enviará uma mensagem queserá ouvida pelos respectivos medidores 310 e 320 (naconfiguração de exemplo da presente Figura 3C) . O medidor320 poderia ir à frente e retransmitir a mensagem, mas istonão faria a mensagem chegar ao medidor 356. Ao invés disso,simplesmente gastaria largura de banda. Com o percurso denó provido' pela pilha de protocolo de RF LAN, os medidores310 e 320 ouvirão a mensagem, mas pelo presente assuntoapenas o medidor 310 retransmitirá a mensagem. A mensagemretransmitida do medidor 310 será ouvida pelos medidores330 e 332, mas apenas o medidor 332 estará no percurso denó, de novo significando que outras partes da célula (taiscomo os medidores 3 50 r 3 53) não receberão uma mensagem queseria inútil para eles. Ambos os medidores 354 e 356ouvirão a mensagem, mas ela é endereçada apenas ao medidor356. Como tal, o medidor 354 pelo presente assuntosimplesmente a ignorará.
Uma vez que a mensagem seja recebida no medidor emquestão (isto é, pretendido), através de RF LAN ou atravésde IP, esse medidor deve desempacotar a requisição e atuarnela. 0 módulo de comunicações no dispositivo puxará amensagem de C12.22 para fora do substrato de rede e aproverá para a placa de registrador 220 (Figura 3B) . Aplaca de registrador 220 desencriptará a mensagem com basenas chaves compartilhadas, e então responderá à requisição,encriptando-a e retornando-a para o ApTitle chamando. Nocaso da RF LAN, a mensagem é simplesmente encaminhada paraa próxima camada acima na célula. As mensagens sãoencaminhadas a partir de uma camada para a próxima, atéelas finalmente atingirem o relê de célula 302, o qual aretransmite através do backhaul de IP 380 para o servidorde comunicações que iniciou a transação.
A Figura 3D ilustra esquematicamente uma configuraçãode exemplo (representando a metodologia e o aparelho) paraa implementação de uma ou mais transferências (viadownload) de acordo com a presente tecnologia. Embora paramuitas finalidades a maior parte da discussão aqui serefira a essas transferências (via download) de firmwarecomo um firmware novo ou atualizado, é para ser entendidoque o presente assunto é igualmente aplicável e envolveplenamente quaisquer transferências (via download) defirmware, independentemente de sua caracterização. Porexemplo, poderia ser devido a circunstâncias e/ounecessidades em particular que o firmware fosse transferido(via download) por ou para um dispositivo em particular quefosse um retorno para uma versão prévia de firmware paraesse dispositivo. Como um outro exemplo, poderia ser que atransferência (via download) de firmware para umdispositivo em particular fosse considerada como sendo amesma 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 oucorrigir, de outra forma, algum assunto corrompido.Pretende-se que todas essas variações na constituição reale na caracterização da natureza e/ou das razões para astransferências (via download) em questão venham no espiritoe no escopo do presente assunto.
Quando um firmware novo ou atualizado é para serinstalado em um sistema 400, uma imagem 410 do freqüente aser transferido será provida para um agente de coleta desistema de medição avançado (AMS) 412 como um arquivo deimagem binário. Uma discussão adicional sobre o agente decoleta 412 é incluída aqui, mas pelo presente é notado queo agente de coleta 412 é responsável pela ruptura da imagembinária única em uma série 420 de blocos discretos 422 quepodem ser distribuídos através de um arranjo decomunicações, tal como uma RF LAN, ou outra mídia. Em umamodalidade de exemplo, uma mídia em conformidade com C12.22pode ser usada. Esses blocos 422 conterão uma prova (hash)ou uma soma de verificação para o bloco em si, para averificação da integridade do bloco, bem como umidentificador de bloco, o qual é representado na Figura 3Dpelos espaços de começo e de fim 424 e 426,respectivamente.
Em geral, quando da transferência de blocos, cada umrompido, o bloco discreto 422 está em sua totalidadepreferencialmente escrito em um registro em uma tabela defabricante para imagens de firmware. Os dispositivos finais440 são configurados para a avaliação desses blocos 422para se determinar sua integridade discreta pelo uso desuas provas (hashes) de nível de bloco. Os dispositivosfinais também podem validar que esses blocos 422 sãomontados (isto é, remontados) na ordem correta. Finalmente,cada dispositivo final é capaz de avaliar a integridade daimagem em geral pela avaliação da CRC (verificação deredundância cíclica) ou prova (hash) para a imagem inteira.
0 presente processo básico para a transferência deblocos de imagem de firmware 4 22 envolve, em parte, umafuncionalidade que é similar àquela usada para a leitura dedados a partir de medidores. Uma difusão contendo os blocosde imagem 422 é enviada para os medidores 440. Os medidores440 indicam, de uma maneira descrita adicionalmente aqui,que eles receberam de forma bem sucedida os blocos deimagem 422. Os medidores que não respondem são tentados denovo em um processo de recuperação para a compensação dequaisquer falhas. Devido à natureza crítica de imagens defirmware, e ao grande número de blocos envolvidos, algunsmecanismos de controle e de retorno adicionais podem serdesejados em alguns casos, para se lidar de forma logísticacom o volume de tráfego.
O gerenciamento do transporte de blocos de firmware422 em um ambiente o qual encontra ou envolve mídia nãoconfiável se torna crítico quando da transferência deimagens de firmware. Em uma configuração de exemplo, umaimagem de firmware de 384 k dividida em blocos de 64 bytesrequererá que 6.144 blocos sejam transferidos completamentede forma bem sucedida, antes de poder ser carregada. Quandoda transferência de blocos através de uma RF LAN, porexemplo, é relativamente provável que pelo menos um nó emuma dada célula falhe em receber de forma bem sucedida umbloco. Essas circunstâncias presentemente são endereçadasde duas maneiras chaves. Em primeiro lugar, é importanteque os blocos sejam capazes de ser transmitidos e recebidosem qualquer ordem. Em segundo lugar, dependendo daconfiabilidade prática da rede subjacente, de acordo com opresente assunto, em alguns casos pode ser praticadodifundir um dado bloco várias vezes, antes de se recorrer atransferências de ponto a ponto de blocos de imagem. Em umaconfiguração de exemplo, foi descoberto que sistemas denível mais alto, isto é, o agente de coleta 412 e/ou umrelê de célula 430, preferencialmente devem transmitir aimagem de firmware pelo menos duas vezes e, em algunscasos, três ou quatro vezes, antes de se recorrer a umatransferência de ponto a ponto de blocos de imagem.
Com referência adicional à Figura 3D, um processo detransferência (via download) de firmware começa com oagente de coleta 412 enviando uma mensagem de difusão paratodos os nós alvos, chamando um procedimento armazenado defabricante ou escrevendo em uma tabela de fabricante nodispositivo. Nesse contexto, um nó alvo pode corresponder aum dispositivo final tal como o medidor 448, o relê decélula 430 ou os medidores 440 incluindo medidoresrepresentativos 442, 444 e 446. Esse comando indica para odispositivo o número de blocos de firmware que deve esperarreceber, 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 querecebeu de forma bem sucedida como parte de quaisquerrequisições de leitura diárias. Adicionalmente, sercolocado no modo de transferência de (via download) defirmware reinicializa para zero um contador de bloco dessedispositivo. Mais ainda, o comando inclui instruções paraos dispositivos finais indicando que nenhum reconhecimentodireto da parte dos medidores deve ser feita. Ao invésdisso, os dispositivos reconhecem esse comando pelorelatório de sua contagem de sucesso como parte do próximociclo de interrogação.
0 agente de coleta 412 é responsável pela avaliação,com base na presença da contagem de sucesso de bloco defirmware, se todos os nós alvos entraram de modo bemsucedido no modo de transferência de (via download) defirmware. Os nós que não foram comutados para o modo detransferência de (via download) de firmware eventualmenteentão serão individualmente contatados pelo agente decoleta 412.
Uma vez que os nós alvos estejam no modo detransferência de (via download) de firmware, o agente decoleta 412 começará a difundir os blocos de firmware 422para os nós alvos 440. Como uma alternativa para atransferência dos blocos de firmware 422 exclusivamentepelo agente de coleta 412, pode ser desejável transferir aimagem de firmware 410 para os relês de célula 43 0 e,então, enviar um comando instruindo-os para difundirem aimagem de firmware 410 na sua respectiva célula. Essemétodo alternativo seria uma abordagem para a redução doscustos de backhaul público de concessionária e para sepermitir que os relês de célula gerenciem melhor a largurade banda nas suas células.
Uma conclusão das transferências de difusão é umprocesso 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 coleta412 começa a avaliar a contagem de sucesso de bloco de cadaum dos nós alvos. Quando um nó tiver completado um conjuntode blocos, ele gravará um evento especial no registro deeventos de histórico de medidor indicando essa conclusãobem sucedida. A maioria dos nós deve ter um conjuntocompleto de blocos uma vez que as transferências de difusãoestejam completadas. Os nós que ainda estejam faltandoprecisarão tê-las transferidas ponto a ponto. Os nós quetenham blocos excessivos faltando após o processo dedifusão ser completado podem ser indicados com um indicadortipo de flag quanto a uma possível manutenção ousubstituição, como estando potencialmente defeituosos.Para facilitação das transferências de ponto a ponto,o agente de coleta 412 chamará um segundo procedimentoarmazenado no dispositivo. Esse segundo procedimento, umprocedimento armazenado de fabricante, proverá uma lista deblocos faltando, por número de bloco. Em uma modalidade deexemplo, a lista de bloco incluirá um número máximopredeterminado de blocos e um byte de status indicando sehá mais do que o número predeterminado de blocos faltando.
Por exemplo, o número máximo predeterminado de blocos podeser regulado para vinte blocos. No uso desse método, amaioria dos medidores receberá todos os blocos e nãoprecisará reportar blocos individuais; contudo, aquelesmedidores que forem blocos faltando poderão serinterrogados quanto a uma manifestação do que eles aindarequerem.
0 agente de coleta 412 usará esses dados de blocofaltando providos pelo respectivo medidor 44 0 para arealização de transferências de bloco de ponto a ponto. Osnós de medidor que não puderem ser contatados serãoreportados pela operadora do sistema. Uma vez que novastentativas ponto a ponto tenham sido completadas, osdispositivos podem ser instruídos para habilitarem o novofirmware. 0 comando para ativação do firmware podecorresponder a um procedimento armazenado de fabricante deC12.22. Se uma data e um horário forem especificados, odispositivo ativará o firmware na data e no horárioespecificados. Se nenhuma data ou horário for provido, odispositivo normalmente será regulado para ativar atransferência (via download) de firmware em uma baseimediata.Uma ativação de firmware bem sucedida pode envolverdois aspectos adicionais. Em primeiro lugar, dispositivosde metrologia selecionados, isto é, medidores, podemempregar não apenas um, mas uma pluralidade de imagensrelacionadas a diferentes aspectos da operação dodispositivo. Em uma configuração de exemplo, pelo menostrês imagens de firmware separadas podem ser empregadas:uma para a placa de registrador de medidor, uma outra paraum microprocessador de rede de área local (LAN) devizinhança e uma terceira para um processador de rede deárea doméstica (HAN) . Em uma configuração de exemplo maisespecífica, o microprocessador de rede de área local devizinhança pode corresponder a um processador de ZigBee.Cada um desses componentes terá sua própria imagem defirmware que pode precisar ser atualizada. Adicionalmente,no decorrer do tempo, novas versões de dispositivo demetrologia as quais requerem diferentes firmwares podem serincorporadas nos sistemas existentes. Nesse caso, uma dadacélula pode ter uma mistura de dispositivos comnecessidades diferentes de firmware. Por exemplo, oprotocolo de ZigBee pode ser usado para comunicação commedidores de gás, visores domésticos, relês de controle decarga e termostatos domésticos.
Com referência presentemente à Figura 3E, é ilustradae representada uma metodologia de exemplo (e um aparelhocorrespondente) para a transmissão de diferentes imagens defirmware para dispositivos finais selecionados. Conformeilustrado na Figura 3E, para o grupo geral de medidores 44 0ilustrados, um primeiro conjunto desses medidores ilustradocom um fundo branco (e geralmente representados pelosmedidores 460, 462, 4 64, 466, e 468) suportam uma imagem defirmware, enquanto um segundo subconjunto de medidoresgeralmente ilustrados 440 ilustrados com um fundo cinza (egeralmente representados pelos medidores 450, 452, 454,456, e 458) suporta uma outra imagem de firmware. Comoresultado, embora os medidores 4 62, 4 64 estejam abaixo dosmedidores 450, 4 52 na hierarquia de rede de célula (ouárvore) e possam ser capazes de trocar imagens de firmwarecom outros, a única forma pela qual os medidores 462, 464podem receber seu firmware é através dos medidores 450,452, os quais no presente exemplo são de um outro tipo dedispositivo.
De modo a se lidar com essas circunstâncias deexemplo, conforme representado na presente Figura 3E, osistema 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 RFLAN, é distribuída para todos os membros da célula quecombinam o endereço de difusão ou multidifusão usado,independentemente de a imagem ser compatível com seuhardware em particular. Isto significa que de acordo com apresente tecnologia, os membros de célula atuam comocomputadores centrais para o firmware. De modo a seatualizarem ambos os tipos de medidores (pelo presenteexemplo representativo), duas atualizações de firmwareprecisarão ser distribuídas. 0 firmware será transferidoprimeiramente para os medidores do primeiro conjunto(geralmente representado pelos medidores 460, 462, 464,466, e 468) e, então, ativado. Em segundo lugar, o firmwareserá transferido para medidores do segundo subconjunto(geralmente representado pelos medidores 450, 452, 454,456, e 458) e, então, ativado. Esse mesmo mecanismo podeser usado para a transferência (via download) de imagens defirmware separadas para microprocessadores individuais nonó final, conforme necessário em uma base caso a caso poruma implementação específica do presente assunto.
Vantajosamente, de acordo com o presente assunto, ocódigo de ativação de firmware não apenas avalia aintegridade dos blocos individuais e a imagem de firmwareem gral, mas também verifica se a imagem é aplicável paraseu hardware real e para qual hardware é direcionado. Emgeral, o comando de ativação será enviado apenas para osdispositivos apropriados pelo uso de um grupo demultidifusão associado à classe de dispositivo. Nãoobstante, checar se a imagem é compatível com o dispositivofinal é uma salvaguarda apropriada praticada em algumasmodalidades 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ãoilustrados como sendo conectados uns aos outros por linhasde seta de cabeça dupla (ilustrados de forma representativaem 470, 472, 474, 476, e 478 na Figura 3D, e em 480, 482,484, 486, e 488 na Figura 3E). Essas interconexões ilustramesquematicamente uma rede autogerada formada pelosmedidores 440 em si pelo presente assunto, em consonânciacom cada outro e o relê de célula 43 0, conforme osmedidores individuais 440 forem ativados. Devido ao fato decada um dos respectivos medidores 44 0 ser independente comrespeito a RF LAN formada, existe uma oportunidade para adistribuição de um software (firmware) de atualizaçãodentre os vários medidores em uma base par a par viral.
No modelo de par a par viral precedente, uma imagem defirmware pode se entregue para o relê de célula de exemplo430. A partir dali, o agente de coleta 412preferencialmente pode enviar um comando de procedimentoarmazenado para o relê de célula 430, indicando que eledeve distribuir essa imagem de firmware para a RF LAN. 0agente de coleta 412 também enviará um comando para os nósde medidor na célula usando uma mensagem de difusão ou demultidifusão, instruindo-os que uma nova imagem de firmwareestá disponível. Uma vez que o comando como esse sejarecebido, o relê de célula 430 torna disponível o firmwarepara seu processador de RF LAN local. Pelo presenteassunto, os nós de medidor 440 nessa célula instruem seusprocessadores de RF LAN para começarem a procurarem blocos.Nesse ponto, os processadores de RF LAN assumem o processode transferência de bloco. De novo, pela presentemetodologia previamente discutido, esses blocos 422 podemser enviados em qualquer ordem.
Esse mecanismo de distribuição de tipo viral mostradopresentemente pode ser muito potente e muito eficiente pelofato de poder ser capaz de fazer melhor uso da largura debanda física disponível. Segundo esse arranjo de par a parpresente viral, nós de medidor individuais 44 0 podem pegarimagens de firmware ou porções de imagens de firmware deseus vizinhos ou pais imediatos, ao invés de precisar pegaros dados diretamente do relê de célula 430 ou do agente decoleta 412. Como resultado, uma porção da célula poderiaestar trocando blocos de firmware enquanto uma outra porçãoda célula poderia estar passando várias mensagens entre nósde medidor 14 0 e o relê de célula 13 0, tudo sem impacto emcada outro.
Com referência à Figura 3F, é ilustrada umarepresentação de diagrama de blocos dos componentes deexemplo do agente de coleta 412 de acordo com umamodalidade de exemplo do presente assunto. O agente decoleta 412 é uma coleção de funcionalidade baseada emsoftware, que prove serviços de C12.22 de ANSI para osdispositivos que compreendem a rede de C12.22, incluindo umou mais relês de célula 430, bem como os dispositivos demetrologia e finais 440. Embora esses componentes sejampreferencialmente baseados em software, aqueles deconhecimento comum na técnica apreciarão várias formasequivalentes de implementação, provendo a mesmafuncionalidade. Conceitualmente, o agente de coleta 412 écompreendido por três componentes principais, o sistema ougerenciador de orquestração geralmente 520, o computadorcentral de relê mestre / autenticação 510 e o servidor ouos servidores de comunicações (representados peloscomponentes ilustrados 512, 514 e 516). 0 agente de coleta412 é implementado preferencialmente de modo a ser capaz dedistribuir o trabalho dentre múltiplos servidores 512, 514e 516, de modo a se facilitar um escalonamento.
Em um sistema de C12.22, o relê mestre 510 é oprocesso de coordenação para o sistema em geral. De modo ase enviarem ou receberem mensagens de C12.22, osrespectivos nós 440 devem ser registrados junto ao relêmestre. Contudo, antes de um respectivo nó ter permissãopara se registrar, ele deve ser autenticado. O computadorcentral de autenticação prove essa funcionalidade napresente modalidade de exemplo. 0 relê mestre ou estação éresponsável pelo processo de aquisição de dados de medidorreal, em comunicação com o medidor através de mensagens deC12.22.
Conforme será entendido por aqueles de conhecimento natécnica, cada um dos respectivos componentes principais doagente de coleta 412 por sua vez é constituído por umasérie de componentes menores e conjuntos de recurso defuncionalidade. O gerenciador de orquestração ou camada 520provê uma coordenação entre esses componentes, e apresentauma API única unificada (interface de camada de aplicativo)para sistemas à frente. 0 gerenciador de orquestração ousistema 520 roda um serviço (ou funcionalidade) único deorquestração mestre e uma série de agentes. Cada servidorfísico separado terá um agente de orquestração para seligá-lo ao sistema maior. As requisições de API sãodirigidas a um serviço (ou funcionalidade) de orquestraçãomestre, o qual, por sua vez, trabalha com os agentes deorquestração para garantir que o trabalho requisitado ou ametodologia seja realizado ou executado.
O relê mestre / computador central de autenticação 510proverá serviços / funcionalidade de registro de C12.22padronizados bem como uma funcionalidade / serviços deautenticação de rede de C12.22 integrados. Uma visão para oprotocolo C12.22 é que, similar ao DNS (servidores de nomede domínio), um relê mestre de C12.22 pode ser criado, oqual seria compartilhado entre múltiplos serviços deutilidade pública, talvez provendo serviços para uma regiãointeira ou um país. Com essa abordagem em mente, aimplementação de um relê mestre de acordo com a presentetecnologia deve prover pleno suporte para o uso de outroscomputadores centrais de autenticação, e para o envio demensagens de notificação para os computadores centraisregistrados. Adicionalmente, o gerenciador de orquestraçãoou camada 520 preferencialmente é implementado de modo aser capaz de receber notificações de relês mestres deoutros fabricantes, significando que uma implementação dopresente assunto poderia ser realizada empregando um relêmestre a partir de uma fonte externa.
Os servidores de comunicações representativos 512, 514e 516 provêem uma funcionalidade de comunicação comdispositivos, tal como para uma análise gramatical etradução dessas comunicações e postar ou retornar dadosconforme necessário. Os servidores de comunicação 512, 514e 516 assim preferencialmente podem compreender uma sériede serviços / funcionalidade para a realização dessafuncionalidade em geral pelo presente assunto. Emservidores de comunicações 512, 514 e 516 há uma série decomponentes principais: um computador central decomunicações de medidor, um spooler de dados, e umgerenciador de evento de exceção. 0 computador central decomunicações de medidor é responsável por ouvircomunicações de rede e envio de comunicações de rede. É ocomponente que "fala" por C12.22 e "interpreta" os dados detabela de C12.19. 0 spooler de dados e o gerenciador deevento de exceção provêem mecanismos para a transmissãocontínua de dados de medição e eventos de exceção,respectivamente, para sistemas à frente.
A Figura 4 mostra pelo presente assunto um exemplo deum quadro inteiro do protocolo em questão para uma mensagemde enlace ascendente, isto é, mensagens de dados enviadas apartir de um ponto final sincronizado para uma relê decélula. Cada campo é explicado aqui pela seção de descriçãode quadro para cada respectiva camada.
Pelo presente assunto, há várias camadas físicaspropostas. Todas usam uma técnica de espectro de dispersãode salto de freqüência. Cada uma delas é pretendida paraser usada para uma localização de mercado específico (paraa América do Norte ou para a Europa) e dentro de uma bandaespecífica, e segue os regulamentos requeridos regionais oulocais.
A camada física denominada PHY-FHSS-NA-915 épretendida para ser usada na banda de ISM de 902 a 928 MHzna América do Norte. Ela está em conformidade com osregulamentos pertinentes da FCC, especificamente as partes15.35, 15.205, 15.209, e 15.247, e em uma modalidadepreferida podem envolver 52 canais. Outras particularidadesdas especificações de transmissor e de receptor para essabanda de 915 MHz, para a América do Norte, bem como asalocações de canal dos mesmos, são bem conhecidas poraqueles de conhecimento comum na técnica, a partir dosregulamentos pertinentes, sem requerer uma discussãoadicional com isso.
A camada física denominada PHY-FHSS-NA-2400 épretendida para ser usada na banda de ISM de 2,4 GHz naAmérica do Norte. Ela está em conformidade com osregulamentos pertinentes da FCC, especificamente as partes15.35, 15.209, 15.247 e 15.249, e em uma modalidadepreferida podem envolver 16 canais. Outras particularidadesdas especificações de transmissor e de receptor para essabanda de 2,4 GHz, para a América do Norte, bem como asalocações de canal dos mesmos, são bem conhecidas poraqueles de conhecimento comum na técnica, a partir dosregulamentos pertinentes, sem requerer uma discussãoadicional com isso.
A camada física denominada PHY-FHSS-EU-868 épretendida para ser usada na banda de ISM de 8 68 MHz naUnião Européia. Ela está em conformidade com osregulamentos pertinentes da ETSI, especificamente as seções300 220 e ERC 70-03. Outras particularidades dasespecificações de transmissor e de receptor para essa bandade 868 MHz na União Européia são bem conhecidas por aquelesde conhecimento comum na técnica, a partir dos regulamentospertinentes, sem requerer uma discussão adicional com isso.
A camada fisica denominada PHY-FHSS-EU-240 0 épretendida para ser usada na banda de ISM de 2,4 GHz naUnião Européia. Ela está em conformidade com osregulamentos pertinentes da ETSI, especificamente as seções300 228 e ERC 70-03 e, em uma modalidade preferida, podeenvolver 16 canais. Outras particularidades dasespecificações de transmissor e de receptor para essa bandade 2,4 GHz na União Européia são bem conhecidas por aquelesde conhecimento comum na técnica, a partir dos regulamentospertinentes, sem requerer uma discussão adicional com isso.
Com referência à camada PHY, isto descreve osparâmetros ajustáveis (isto é, "passíveis de tweak") (tweaksão dicas para otimizar o desempenho de um sistemaoperacional, alterar características de um programa,configurar opções escondidas, etc.) dessa camada PHY. ParaPHY_Synch_Length: o comprimento em bits do campo Synch, aseqüência de bit de sincronização da PPDU. ParaPHY_SFD_Value: o valor do campo de SFD da PPDU. Este valordeve ser escolhido com propriedades de autocorrelaçãoapropriadas para se permitir uma detecção confiável decomeço de quadro. Os valores recomendados são dados natabela a seguir. O bit mais significativo do PHY_SFD_Valueé enviado primeiramente na interface de ar, imediatamenteapós o preâmbulo. Estes valores de SFD têm ortogonalidadesuficiente para serem usados com a finalidade de isolamentode várias redes coexistentes. Para PHY_RSSI_Average_Time: otempo 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 PHYpreferencialmente podem ser considerados conforme se segue.
Para PHY_Synch_Length: 32 bytes; para PHY_SFD_Value: 0xB127(com o bit mais significativo sendo enviado primeiramentena interface de ar); e para PHY_RSSI_Average_Time: 1 ms.
Quanto a parâmetros de acesso a meio, divisões detempo e de freqüência são gerenciados com o uso da técnicade Aloha com intervalo (cujos detalhes são bem conhecidospor aqueles de conhecimento comum na técnica). O tempogeralmente é dividido em intervalos de tempo (TS) idênticose em cada mudança de TS (intervalo de tempo), a freqüênciasalta de um canal para um outro canal de acordo com umaseqüência de salto de freqüência. A camada de MAC estáencarregada da sincronização. Uma vez que tipicamente otráfego em qualquer ponto no tempo é lento, a técnica deAloha com intervalo é uma seleção apropriada. Cada medidorpor padrão está no modo de receptor e empurra os dados nomeio quando ele quiser falar. Esse método geralmente podeestar produzindo um número relativo de colisões, mas, emcondições de operação normais, espera-se que as colisõessejam mais baixas do que as colisões devido ao ambiente comruído de bandas de ISM. Contudo, o presente protocolointencionalmente gerencia repetições para compensação dessefenômeno.
A camada física pode proporcionar às camadas acimadela um instantâneo da qualidade de enlace entre o pontofinal e o remetente da mensagem. A camada física faz issopela 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, osquais são uma seqüência alternada de zero e um. Isto é umaleitura média por PHY_RSSI_Average_Time ms. Quando a camadafísica detecta o começo de delimitador de quadro, ela páraa leitura de RSSI e salva o valor para proporcioná-lo maistarde para a camada de MAC em conjunto com a mensagemrecebida.
0 RSSI também é uma medição do nível de interferênciaem um dado canal quando usado fora da recepção de umapresente mensagem de rede de protocolo. Isto é usado, porexemplo, nos processos de análise de ambiente.
Em todos os casos, o valor de RSSI enviado para acamada de MAC pela camada física preferencialmente não éuma mera leitura do registrador de RSSI de um grupo dechips de transceptor. O valor preferencialmente éprocessado para refletir o nível de potência real do sinalentrando, isto é, um ganho de LNA e perdas de inserção defiltro devem ser levados em consideração no valor de RSSIencaminhado para a camada de MAC.
O RSSI é formatado como um byte sinalizado único. Ovalor é dado em dBm. Sua faixa teórica, portanto é de -12 8dBm a +12 7 dBm.
Os dados preferencialmente são transmitidos no formatoterminal pequeno (o bit menos significativo primeiro). Umaordenação de bit também é feita com o bit menossignificativo primeiro.
A correção de erro antecipada (FEC) usada pela camadafísica é um código de Reed-Solomon entrelaçado (32, 38) comsímbolos no Campo de Galois (GF) (256) . As etapas paracodificação são:
• Se o comprimento de MPDU for maior do que 28 bytes,dividir a MPDU em N blocos de 28 bytes. Se ocomprimento 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 deredundância com o código de RS (38.28) . Se necessário,o último bloco é preenchido com zero para se permitiro uso do mesmo algoritmo de computação para todos osblocos.• Escrever os blocos de dados e os bytes de redundânciana tabela de entrelaçamento. Cada bloco ocupa umalinha nesta tabela.
• Construir a LPDU começando a partir da primeira colunada 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ãoenviados na interface de ar. 0 campo de comprimento docabeçalho de PHY inclui a FEC, mas não inclui o
preenchimento com zeros, é computado com:
Comprimento = 38 * N - (número de zeros adicionados nobloco N)
A Figura 5 ilustra a fragmentação da MPDU em blocosantes da codificação de Reed-Solomon; em outras palavras, aFigura 5 mostra blocos de dados para uma codificação /decodificação de FEC.
A Figura 6 mostra uma presente estrutura de tabela deentrelaçamento de exemplo para codificação / decodificaçãode FEC. Esse entrelaçamento é feito no sentido de byte,isto é, o primeiro byte de bloco 1 é enviado, então, oprimeiro byte de bloco 2. Essa operação é continuada até oúltimo byte de FEC ser enviado. Após essa codificação deReed-Solomon e um entrelaçamento, os bytes de redundânciaestão no fim do quadro, conforme mostrado pela presenteFigura 7.
As etapas para a decodificação são as mesmas para essacodificação, mas em ordem inversa:
• Preencher a tabela de entrelaçamento começando com aprimeira coluna. A partir do campo de comprimento docabeçalho de PHY e do tamanho de bloco, é possívelconhecer onde o preenchimento com zeros precisa serinserido.
• Para cada linha na tabela de entrelaçamento, corrigiros erros com o código de RS (3 8, 28) .
· Retirar a FEC e remontar a MPDU.
A codificação de Reed-Solomon preferencialmente usadano presente protocolo é um código de RS (38, 28) . É umaversão resumida de um código de RS (255, 245) com símbolosem GF (256) . Isto significa que os símbolos do código sãobytes e que para cada bloco de 2 8 bytes, são apensados 10bytes de redundância adicionais. Este código tem umadistância de Hamming de 11 e permite a correção de 5 byteserrôneos por bloco.
Mais particularmente, cada byte da mensagem éconsiderado como um elemento de GF (256) . Uma referênciaaqui a esses problemas será como símbolos. Todas asoperações feitas com esses símbolos (adição, subtração,multiplicação e divisão) devem ser feitas de acordo com asleis 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áriasrepresentações úteis: uma representação binária{b7beb5b4b3b2bibo} , uma representação polinomial b7a7 + b6a6 +b5a5 + b4a4 + b3a3 + b2a2 + bia + b0 e uma representaçãoexponencial am. Nas últimas duas representações, α é umelemento primitivo de modo que ρ (a) =0. A representaçãobinária ou polinomial é útil para a adição e arepresentação exponencial é útil para multiplicação. Todosos elementos de GF (256), exceto por zero, têm umarepresentação exponencial, o campo completo pode serescrito 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 docodificador / decodificador, é necessário adicionar emultiplicar os símbolos em GF (256) . Uma adição éprontamente realizada com a representação binária oupolinomial dos símbolos. A operação é equivalente a umaadição de módulo 2 de cada bit, por exemplo:
0010 1100 + 1000 1111 = 1010 0011
A multiplicação é relativamente mais difícil porqueuma conversão para a forma exponencial do símbolo énecessária. Uma tabela de consulta preferencialmente éusada para essa finalidade. Como um exemplo, umamultiplicação a seguir dos dois símbolos do exemplo prévio:
0010 1100 χ 1000 1111
O primeiro símbolo (44) tem a representaçãoexponencial α190, o segundo símbolo (143) tem arepresentação exponencial α90. 0 produto é a190a90 = a280 =a255+25 = a25 p0rque a255 = 1. Essa tabela pode ser usada deoutra forma para conversão do resultado em forma binária eobter 44 * 143 = 226.
Com referência ao presente codificador de Reed-Solomon, conforme implementado preferencialmente de acordocom o presente assunto, conformando-se à convençãoestabelecida na teoria de codificação, poder-se-ia usaraqui a representação polinomial para as mensagens. Istosignifica que o presente bloco de dados de 28 símbolos,{u27, u26, u25, ..., Ui, Uo} , pode ser escrito u(x) = u27x27 +U26X26 + U3X3 + U2X2 + UxX + U0. O 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ódigode 38 símbolos (mensagem + símbolos de redundância) podeser escrita c (x) = c37x37 + c36x36 + C3X3 + c2x2 + CiX + C0. 0processo de codificação de Reed-Solomon é equivalente a umadivisão da mensagem por um polinômio gerador G(x) . Istopode ser implementado com um registrador de deslocamento deretorno linear, conforme mostrado na presente Figura 8.Isto é similar a, mas diferente de um codificador de CRCconvencional. A diferença é que no presente assunto cadamultiplicação por um coeficiente e cada adição têm que serentendidas como multiplicação e adição no GF (256).
Na implementação de registrador de deslocamentorepresentada na presente Figura 8, os gi são elementos deGF (256). O registrador de deslocamento é primeiramenteinicializado com zeros. Os símbolos da mensagem então sãodeslocados para o registrador, começando com u27 eterminando com u0. Após o bloco de dados inteiro ter sidoempurrado para o registrador de deslocamento, o conteúdo doregistrador é o resto da divisão. Estes símbolos são ossímbolos de FEC e eles são apensados à mensagem inicial daforma a seguir:
<formula>formula see original document page 108</formula>
Como com a computação de CRC convencional, os fatoresmultiplicativos no registrador de deslocamento são dadospelos 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 seencontrarem os coeficientes gi, o resultado é:
G(x) = a55 + α120* + α 57Jf2 + Cr126X3 + α 136X4 + α 198X5 + ar 125X6 + α ι04χ7 + α 24X8 + α76 χ9 + χ10
A primeira etapa do processo de decodificação de Reed-Solomon é a sindrome de computação. Para um bloco recebidode 38 bytes, 10 síndromes preferencialmente são computadas.Se a mensagem recebida for {r37, r36, ..., r2, ri, r0}, arepresentação polinomial a seguir se aplicará:
R(x) = W37 + W™ + ■ ·' + ηJf + r0
As 10 síndromes (S1, S2, ... Si0) serão computadas comR(x), conforme mostrado abaixo:
$ = for 1</<10
Se as 10 síndromes forem iguais a zero, não haverá umerro detectável na mensagem e o processo de decodificaçãoparará aqui. Obviamente, há uma possibilidade de um erroindetectável, mas, preferencialmente, isto será detectadopela 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:
ELP{x) = 1 + ELP1X + ELP2X2 +·■■ ELPvXv, ν <5
0 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(x), um algoritmoiterativo é usado, o algoritmo de Berlekamp-Massey. Umadescrição de pseudocódigo desse algoritmo é conforme sesegue:Input: Sj, S2, Si0
Initialization:
Len=OELP(x)=lPELP(X)=Ij=ldm=lfor k=l to 10
(as síndromes)
(o polinômio localizador de erro atual)(o polinômio localizador de erro prévio)
(a discrepância prévia)
Len
d = Sk + ΣELPiSk-,
/ = I
ifd=0
else
endend
j=j+l
if 2Len > k then
(computar discrepância)
(nenhuma mudança no polinômio)
else
end
ELP(x) = ELP(x) - dd~J xj PELP(X)j=j+l
temp(x)=ELP(x) (armazenamento temporário)
ELP(x) = ELP(x)-dd~] xJPELP(x)
Len=k-LenPELP(x)=temp(x)dm=dj=lUma vez que o polinômio localizador de erro tenha sidocomputado, as raízes desse polinômio são encontradas. Parase 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 opacote inteiro deverá ser rejeitado. 0 inverso das raízesde ELP(x) é denominado os localizadores de erro. Umlocalizador de erro indica a posição de um erro namensagem, conforme se segue.
ELP(Y) = 0, Ye GF(256) => X -j é o localizador de erro
—> if X = Ct^ t o símbolo na posição k é corrompido
Como um exemplo, é encontrado que ELP (a235) = 0 , a"235 éum localizador de erro. O inverso de a235 é computado, oqual é a"235 = a255a~235 = a20. É concluído nessa instância deexemplo que o símbolo na posição 20 está corrompido, istoé, que r20 na seqüência {r37, r36, ..., r2, r1( r0} . Nesteestágio do processo de decodificação, se o padrão de errofor corrigível, as posições de todos os símboloscorrompidos no bloco serão conhecidas. O conjunto delocalizadores de erro é:
[XuX2i--Xt,), ElP(XJi) = Q
Uma técnica presente para se acelerar potencialmente acomputação das raízes de ELP(x) é tentar apenas oselementos de GF (256) que apontem para erros no bloco, istoé: {l, a-1, a"2, a"3, ..., a"37}.
A próxima etapa preferencialmente pelo presenteassunto é corrigir os erros. Isso envolve a computação dopolinômio avaliador de erro, definido pelo seguinte:
EEP(x) = S(x)ELP{x) mod(x10)
onde um novo polinômio é introduzido, cujos coeficientessão as síndromes
S (x) = S, + S2X 4- SyX2 + -.. + S1()Jr9
O mod(x10) na definição de EEP(x) significa que todosos termos do grau 10 ou mais altos são descartados. Tambémenvolve o uso de um polinômio denominado a derivada formaldo polinômio localizador de erro, conforme se segue:
DER _ ELP (x) - ELPi + ELPiX2 + ELP5X4
O erro no símbolo indicado pelo localizador de erro Xké dado por:
<formula>formula see original document page 112</formula>
0 símbolo corrigido é:
Novo valor de símbolo = valor antigo de símbolo + Error(k)
0 formato do quadro de camada física é representadopela presente Figura 9. O campo de Synch do Preâmbulo (vejaa Figura 9) do quadro de camada física é composto por umaseqüência de zero e um alternados. É pretendido permitirque o receptor remoto detecte a presença de uma mensagementrando e realize uma recuperação de relógio de dados. Eleindica um quadro iminente e vantajosamente também é usadopelo receptor para a medição da intensidade de potência(RSSI) do sinal recebido. 0 comprimento de campo Synch édado pelo parâmetro de camada PHY PHY_Synch_Length. 0 valorpadrão para este parâmetro é de 32 bits (4 bytes).
O campo de começo de delimitador de quadro (SFD) (vejaa Figura 9) é de dois bytes de comprimento. Ele sinaliza ofinal do preâmbulo e o começo do cabeçalho de PHY. Ele temum valor fixo pré-definido dado pelo parâmetro de camadaPHY PHY_SFD_Value. Se várias redes operadas por diferentesserviços de utilidade pública coexistirem na mesma área, épossível pelo presente assunto atribuir um valor de SFDespecífico a cada rede. Como apenas os pacotes com o valorde SFD direito são considerados, isto impedirá um pontofinal de processar os pacotes pretendidos para uma outrarede. Quando usado em conjunto com a ID de serviço deutilidade pública, este recurso vantajosamente aumenta onúmero possível de redes coexistentes na mesma área.
Mais ainda pelos presentes recursos, como uma opção adetecção de SFD pode ser configurada pelo presente assuntopara aceitação do pacote apenas se 15 dos 16 bitscombinarem com o PHY_SFD_Value. Quando usada com FEC, essaalternativa serve para aumento da imunidade a ruído pelopresente 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 adistinção dos diferentes serviços de utilidade pública queusam este protocolo na mesma localização. Vantajosamenteisso evita um serviço de utilidade pública entrar em umacélula pertencente a um de seus competidores. Quando a UIDdo pacote não combina com a UID definida no ponto final, opacote recebido é descartado. Os dois bits subseqüentes dopacote preferencialmente são reservados, isto é, não usadosinicialmente, para preservação de usos futuros, epreferencialmente deve ser regulado para 0.
Os bits de Length (comprimento) indicam o comprimentoda MPDU, em bytes. Quando o número indicado de bytes érecebido, a camada física (se o resultado da decodificaçãode FEC for um pacote válido) indica a chegada de um quadrocompleto ã camada de MAC, a qual verificará sua integridade(CRC). Então, a camada PHY, a qual por padrão está no modode recepção, procura o próximo preâmbulo.
Para adicionar alguma robustez ao cabeçalho de PHY quenão tem uma CRC, os campos UID, RSD e Lengthpreferencialmente são complementados bit por bit, pelopresente assunto. Se os campos complementadores nãocombinarem com os campos associados, o pacote recebido serádescartado.
Com referência ao Corpo de Quadro (veja a Figura 9), aunidade de dados de protocolo de MAC (MPDU) contém toda ainformação requerida no nível de camada de MAC. 0 corpo dequadro também contém bytes redundantes adicionados deacordo com o algoritmo de FEC explicado aqui acima.
Na descrição aqui de cada camada no documento, umainterface e serviços com a camada superior são apresentadosda mesma forma. Uma figura mostra as diferentes interaçõesentre as camadas. Há três fluxos diferentes de informaçãoentre eles, especificamente, requisições, confirmações eindicações. Estas comunicações internas diferentes entãosão explicadas.
Com referência a requisições, Layer-Name_Request-Name,elas são os serviços oferecidos por uma camada para acamada acima. Quando o serviço não é necessário pela camadaimediatamente acima, mas pela uma, duas ou três vezessuperior, as camadas intermediárias devem encaminhar oserviço. O usuário opcionalmente pode criar um atalho nascamadas médias, se desejado, para modalidades emparticular.
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 presenteassunto. As confirmações nem sempre são enviadasimediatamente após uma requisição; ela depende do serviço.
A abordagem preferida é estabelecer um número para arequisição e, então, proporcionar o mesmo número quando aconfirmação for enviada, de modo a se evitar umdesentendimento. Note que o número associado à requisiçãonã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 elasreportam um evento. A camada que envia uma indicação nãoespera qualquer confirmação.
Ainda com respeito à criação de interfaces e serviçosdentre camadas, a camada física está encarregada de enviare receber pacotes de rádio no meio. Portanto, pelo presenteassunto, por padrão, a camada física está no modo derecepção. Assim que um pacote é transmitido, a camadafísica comuta de volta para o modo de recepção. As mudançasde canal preferencialmente são requisitadas pela camadasuperior, a camada de MAC. A camada física também gerenciao transceptor concernente a sua interface de comunicação,calibração de canal, status de trava de PLL, leitura deRSSI e seleção de modo. No modo de transmissão (Tx) , elacomputa uma FCS (com base no código de RS) e a adiciona aopacote; ela então adiciona um cabeçalho físico (PHY-Header)e um preâmbulo. Finalmente, ela codifica e modula o pacotede rádio na taxa e na freqüência requeridas. No modo derecepção (Rx), ela ouve o meio até encontrar um preâmbulo.Assim que reconhece o começo de delimitador de quadro nofim do preâmbulo, ela salva o tempo de recepção (SACT) emede a intensidade de potência de entrada (RSSI). Então,ela demodula e decodifica o pacote de rádio. Após a remoçãodo preâmbulo e do cabeçalho, ela corrige o pacote, senecessário (e, se for possível) e indica para a camada deMAC a chegada de uma nova mensagem. A datação da mensagemdeve ser acurada o bastante para permitir a operaçãoapropriada do protocolo, conforme discutido de outra formaaqui com referência à camada de MAC.
A camada física propõe serviços diferentes, conformerepresentado pela Figura 10.
Em conjunto com as requisições de PHY, referenciadascomo PHY_Request_Send, o objetivo é enviar um pacote peloenlace 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çãopode ser descrita conforme se segue. A camada de MACrequisita a partir da camada PHY o envio de um pacote. 0canal é proporcionado com a requisição. A camada PHY enviao pacote no tempo indicado pelo MAC. Uma informação desincronismo pode ser proporcionada por várias formasalternativas pelo presente assunto, quanto a qual o usuárioé livre para decidir. Assim que o pacote é transmitido, acamada física comuta de volta para o modo de recepção nocanal padrão de intervalo de tempo e confirma para a camadade MAC o status da transmissão.
Em conjunto com as requisições de PHY para mudança decanal, referenciadas como PHY_Request_Change_Channel, oobjetivo é mudar o canal de escuta. Os argumentos deentrada requisitados são Channel information (informação decanal). A operação pode ser descrita conforme se segue. Acamada de MAC requisita a partir da camada PHY para mudar ocanal de recepção padrão imediatamente.
Em conjunto com as requisições de PHY para leitura deum valor de RSSI, referenciado como PHY_Request_Read_RSSI,o objetivo é ler o valor de RSSI. Não há argumentos deentrada requisitados. A operação pode ser descrita conformese segue. A requisição em questão pede à camada PHY paraler imediatamente o valor instantâneo de RSSI no canalatual.
Em conjunto com as requisições de PHY para começar ouparar, referenciadas como PHY_Request_Start_Stop_Rx, oobjetivo é 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 descritaconforme se segue. Esta requisição pede à camada PHY paracomeçar ou parar imediatamente de escutar o canal padrãoatual. Preferencialmente, pelo presente assunto, arequisição de Stop é usada principalmente quando uma faltade potência é detectada, para se poupar energia.
Em conjunto com a confirmação de PHY, referenciadacomo PHY_Confirmation_Send, o objetivo é a Resposta de umaPHY_Request_Send. Os argumentos de saída requisitados são obyte de status (Status byte). A operação pode ser descritacomo uma confirmação do status de uma mensagem transmitida.Ela pode ser Send_Ack, PLL_Unlock ou qualquer tipo deerros.
Em conjunto com a confirmação de mudança de PHY,referenciada como PHY_Confirmation_Change_Channel; oobjetivo é 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 umaconfirmaçã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 desaída requisitados são o RSSI. A operação pode ser descritacomo 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 ouparar a recepção, referenciada comoPHY_Confirmation_Start_Stop_Rx, o objetivo é a resposta deuma PHY_Request_Start_Stop_Rx. Os argumentos de entradarequisitados são o byte de Status. A operação pode serdescrita como apenas confirmar se a requisição foi bemrealizada.
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 desaída requisitados são MPDU, SACT, e RSSI. A operação podeser descrita como após a recepção de uma mensagem, a camadaPHY remover seu cabeçalho e proporcionar a MPDU para acamada de MAC. A camada de PHY também indica o RSSI medidodurante a recepção e o valor de SACT (veja o capítulo decamada de MAC para a definição do SACT) quando o SFD tiversido capturado.
A camada de enlace de dados é dividida em duassubcamadas, a camada de MAC e a camada de LLC. A camada deMAC tem várias tarefas, por meio das quais ela organiza umatransmissão de dados nos canais de RF e gerencia asincronização.
Especificamente, com referência à Verificação deRedundância Cíclica (CRC), o primeiro papel da camada deMAC é detectar erros nos datagramas recebidos. Antes datransmissão, a camada de MAC computa uma CRC com base nopacote a ser transmitido e a adiciona no final do pacote.Devido a essa função, na recepção do pacote, a camada deMAC tem a capacidade de aceitar ou descartar mensagens,dependendo do valor dos códigos.
A segunda tarefa da camada de MAC é a montagem e adesmontagem do datagrama. A camada de MAC sabe que tipo demensagem o medidor recebeu, quem a enviou (SA) e para quemela é endereçada (DA). Portanto, a camada de MAC tambémrealiza reconhecimento. Quando uma mensagem é recebida, umamensagem de reconhecimento é transmitida de volta no mesmointervalo de tempo com um argumento de ACK ou de NACK, ecom o número de quadro. Esta mensagem de reconhecimento nãoserá adicionalmente reconhecida; a camada de MAC prove umreconhecimento em cada salto da mensagem, mas não há um ecode ponta a ponta de MAC.
Uma outra tarefa é o gerenciamento de vizinhança.Devido às mensagens recebidas e a seu cabeçalho, a camadade MAC gerencia uma tabela, onde várias indicações sobre osvizinhos a um salto são salvas. Quando um vizinho nãotransmitiu coisa alguma por um longo tempo, ele éconsiderado como tendo sido deixado e é removido da tabela.Esta tabela é usada para várias finalidades, comosincronização. Ela também é compartilhada com a camada derede para se permitir um roteamento de mensagem.
Uma outra tarefa realizada pela camada de MAC é ogerenciamento de sincronização. A camada de MAC reajusta ocomeço de intervalos de tempo na escuta de um tráfego e norecebimento de pacotes de sincronização. Devido ao fato deconhecer a divisão de tempo e a seqüência de salto defreqüência, ela pode escolher o canal a usar. Parasincronização com outros pontos finais, isto é, se nãohouver tráfego, a camada de MAC envia sinais de orientaçãoperiódicos.
O que vem a seguir descreve os parâmetros da camada deMAC, mais especificamente, a escuta de uma variedade deparâmetros os quais são ajustáveis (isto é, passíveis detweak). Ele provê uma descrição de cada parâmetro e algunscomentá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 presenteassunto de protocolo opera, os valores padrões dosparâmetros de MAC mudam, conforme será entendido poraqueles de conhecimento comum na técnica, sem se requereruma discussão detalhada adicional dos mesmos.
MAC_Beacon_Period_SYNC
Descrição: O período dos sinais de orientação enviados porum ponto final sincronizado, quando não tiver outrasmensagens a enviar. Corresponde ao período máximo admitidode inatividade de rádio.
Comentários: 0 valor deste parâmetro depende da deriva derelógio e das margens de intervalo de tempo. Deve permitirque a rede fique sincronizada mesmo se vários sinais deorientação não forem ouvidos (isto é, deve ser menor do queMAC_Neighbor_Timeout). Quanto mais importante for a derivade relógio, mais curto deverá ser o período de sinal deorientação. Os sinais de orientação não são enviadosexatamente em cada período, mas são randomizados de modo ase evitarem colisões de sinal de orientação.
MAC_CELL_Leaving_Process_Duration.
Descrição: 0 intervalo de tempo entre a recepção de umSYNC_ACK de uma outra célula (considerado melhor pelo pontofinal) e o momento em que o ponto final realmente comuta acélula.
MAC_CELL_Switch_Hysteresis
Descrição: Este parâmetro define a histerese no processo dedecisão para controle de transmissão adaptativo e célula.
MA C_ CELL_ We i gh t_CSI
Descrição: No processo de comutação de célula, esteparâmetro define o peso do tamanho de célula na seleção decélula.
MA C_ CELL_ We i gh t_GPD
Descrição: No processo de comutação de célula, esteparâmetro define o peso do GPD na seleção de célula.
MAC_CELL_Wei ght_Leve1
Descrição: No processo de comutação de célula, esteparâ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 paraincluir todos os parâmetros influenciadores (tolerância,temperatura e envelhecimento).
Comentário: Quanto melhor for a acurácia de cristal, maisfacilmente a sincronização será mantida.
MAC_Discovery_Beacon_Period:
Descrição: 0 período entre dois sinais de orientação dedescoberta durante a fase de descoberta.
Comentário: Este deve ser maior do que o tempo necessáriopara o envio de um sinal de orientação de descoberta. Eletambém é dependente de quão rapidamente o firmware /hardware pode lidar com a transmissão de um sinal deorientação.
MAC_Excell en t_Connec ti vi ty__ Threshol d:
Descrição: O número mínimo de pais de SYNC a partir do qualum nó é considerado como tendo um grau de conectividadeexcelente.
MA C_ 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.
MA C_ GPD_ TD:
Descrição: Este parâmetro é usado para modelagem do atrasode propagação fixo através de cada nó da rede. Ele é usadopara computação do GPD (atraso de propagação médio global).
Comentários: Aumentar o valor deste parâmetro fará com queo sistema proporcione uma vantagem para os percursos commenos saltos.
MA C_HFC_Max:
Descrição: Especifica a faixa do contador de hardware.
MAC_HF_Length:Descrição: A extensão em intervalos de tempo de umhardware.
Um hiperquadro é uma sucessão de intervalos de tempo quesegue a hiperseqüência de salto.
Comentário: Esta extensão é o produto do comprimento desuperseqüência pelo número de canais.
HF_Length=Number_of_Channels* Hopping_Super_Sequence_LengthMAC_Hopping_Super_Sequence_Length:
Descrição: O comprimento de uma superseqüência de salto defreqüência, também o número de seqüências de salto básicasusadas em uma hiperseqüência.MAC_Listening_Window_Length:
Descrição: Comprimento da janela de escuta durante a fasede descoberta.
Comentários: Aumentar este comprimento diminuirá aprobabilidade de colisão entre sinais de orientaçãoforçados, mas desacelerará o processo de descoberta, sevárias fases de descoberta forem necessárias para seencontrar um pai de SYNC.
MAC_LPD_Max:
Descrição: Valor máximo possível para o LPD (atraso depropagação local médio).
MAC_LPD_NAVG:
Descrição: O comprimento de janela médio deslizante usadopara a computação do LPD (atraso de propagação localmédio).
Comentário: esta janela deve ser menor do que o valor deMAC_NeighborJTimeout.
MAC_LPD_RSSI:
Descrição: Fator usado para inicialização do LPD (atraso depropagação local médio) a partir da leitura de RSSI.
MAC_LPD_SwitCh:
Descrição: Fator usado para a inicialização de LPD (atrasode propagação local médio) a partir da leitura de RSSI.
MAC_Max_Di scovery_Phase_Period:
Descrição: 0 período máximo entre duas fases de descobertapara um ponto final não sincronizado.
Comentário: Isto é usado após as fases de descoberta malsucedidas de MAC_Max_Nb_of_Discovery_Phases e deve sermuito 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 malsucedidas antes do aumento do seu período.
Comentários: A razão para este parâmetro é acalmar ospontos finais órfãos. Deve ser regulado alto o bastantepara tornar possível que um ponto final descubra váriascélulas.
MA C_Max_Nb_of_Neighbors:
Descrição: 0 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 finaltenta enviar uma requisição de SYNC para cada pai de SYNCem potencial.
MAC_Max_Nb_of_Transmitted_Bytes_sTS:
Descrição: O número máximo de bytes que podem sertransmitidos durante um subintervalo de tempo. Isto incluio pacote inteiro, isto é, MPDU, cabeçalho de PHY epreâmbulo.
Comentário: Este valor combinado com a taxa de dados afetao comprimento de Sub_TS.MAC_Max_Nb_ofJTransmi tted_Bytes_TS :
Descrição: 0 número máximo de bytes que podem sertransmitidos durante um intervalo de tempo. Isto inclui opacote inteiro, isto é, MPDU, cabeçalho de PHY e preâmbulo.Comentário: Este valor depende da taxa de dados, docomprimento de intervalo de tempo e das margens deintervalo de tempo.
MAC_Max_Packet_Length:
Descrição: 0 comprimento máximo de pacotes de PDU (expressoem bytes) que a camada de MAC autoriza a camada superior aenviar (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 descobertapara um ponto final não sincronizado.
Comentário: Este deve ser maior do que o tempo necessáriopara o envio dos sinais de orientação de descoberta maisMAC_Listening_Window_Length.
MAC_Nb_of_Basic_Hopping_Sequences:
Descrição: O número de seqüências de salto de freqüênciabásicas que um ponto final pode gerar. Cada seqüência desalto é uma sucessão de todos os canais pré-definidos. Cadaum dos canais MAC_Number_of_Channels aparece uma vez eapenas uma vez nesta sucessão.
Comentário: Este valor deve ser maior do queMAC_Hopping_Super_Sequence_Length.
MAC_Nb_of_Sub_TS:
Descrição: 0 número de subintervalos de tempo em umintervalo de tempo. 0 começo de um Sub-TS marca o começopotencial da transmissão de um pacote.
Comentários: O número de Sub-TS é ((TS_Length-2 *TS_Margin)/Sub_TS_Length). É assumido que os valores decomprimento são escolhidos para se tornar este um inteiro.
MAC_Max_nb_of_downlink_buffered_packets:
Descrição: O número máximo de pacotes que um ponto finalpode salvar em sua memória. Ele concerne apenas aos pacotesindo do mestre de célula para os pontos finais (enlacedescendente).
MAC_Max_nb_of_uplink_buffered^packets:
Descrição: O número máximo de pacotes que um ponto finalpode salvar em sua memória. Ele concerne apenas aos pacotesindo dos pontos finais para o mestre de célula (enlaceascendente).
MAC_Neighbor_Timeout:
Descrição: O limite de tempo para a camada de MAC decidirque um ponto final não é um vizinho mais porque a últimarecepção ocorreu mais do que após o MAC_Neighbor_Tímeout.Comentários: Isto depende da deriva de relógio e dasmargens de intervalo de tempo. Um ponto final não deve serconsiderado um vizinho se houver uma chance de ele nãoestar mais sincronizado.
MAC_Number_of_Channels:
Descrição: O número de canais usados nas seqüências desalto de freqüência básicas.
Comentários: O valor mínimo para este parâmetro é fixadopelos regulamentos de espectro de dispersão: 15, 20, 25 ou50 canais, dependendo dos países e dos recursosinteligentes de salto de freqüência.MAC_RSSI_Sampling_Rate:
Descrição: Freqüência de leituras de RSSI durante a análiseambiental para a computação de RSSI médio e da função deautocorrelação de RSSI.
MAC_RXI_Decay:
Descrição: Esta constante é usada para computação doindicador de taxa de recepção (RXI). 0 RXI é periodicamentemultiplicado por esta constante para se fazer com que oindicador decaia no tempo quando nenhuma mensagem forrecebida.
MAC_RXI_Increment:
Descrição: Esta constante é usada para computação doindicador de taxa de recepção (RXI). Mediante orecebimento 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ãoconsiderados como sendo uma indicação de um enlaceconfiável. Isto é usado na computação de números de méritopara a escolha de pais de sincronização.
MAC_SACT_Resolution:
Descrição: 0 valor do bit menos significativo dotemporizador de SACT, quando o valor deste temporizador fortrocado entre os pontos finais.
Comentário: 0 temporizador de SACT pode ser localmenteimplementado com uma resolução mais alta dada peloparâmetro MAC_FW_Accuracy.
MAC_Sub_TS_Length:
Descrição: 0 comprimento de um Sub_TS. Ele corresponde aocomprimento 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 umnúmero inteiro de Sub_TS por TS.
MA C_SYNC_Di sc_Wei gh t_ CSI
Descrição: Na fase de descoberta, este parâmetro define opeso do CSI de vizinhos no processo de seleção de pai desincronização.
MAC_SYNC_Disc_Weigh t_GPD
Descrição: Na fase de descoberta, este parâmetro define opeso do GPD de vizinhos no processo de seleção de pai desincronização.
MAC_SYNC_Disc_Weight_Level
Descrição: Na fase de descoberta, este parâmetro define opeso do nível de vizinhos no processo de seleção de pai desincronização.
MAC_SYNC_Father_Request_Beacon_Threshold:
Descrição: Duração usada para se determinar se um pontofinal ainda está em sincronização com um pai, antes daaceitação que um outro ponto final fique sincronizado comele. Se uma mensagem a partir de um pai saudável tiver sidorecebida neste tempo, não haverá necessidade de requisitarum sinal de orientação a partir dele antes de responder auma requisição de SYNC.
Comentário: Este valor deve ser menor do queMAC_Beacon_Period_SYNC.
MAC_SYNC_Request_Period:
Descrição: O período mínimo entre duas requisiçõesdiferentes de SYNC enviadas para o mesmo pai de SYNC empotencial.MAC_Traffic_Density_max
Descrição: Qualquer ponto final na malha ajustará suajanela de randomização de transmissão de modo a se evitar acriação de uma densidade de entrada de tráfego acimadaquele limite para cada um de seus pais.
Comentários: O valor deste parâmetro deve sempre ser menordo que um. Os valores próximos de um podem melhorar o ritmode transferência máximo do sistema, mas aumentam o risco deemperramento do tráfego de dados com colisões.
MAC_Traffic_Monitoring_Window
Descrição: 0 comprimento da janela média deslizante usadapor um ponto final para a monitoração do tráfego devizinhos. Este comprimento é expresso em unidades deintervalos de tempo.
MAC_TS_Length:
Descrição: 0 comprimento de um intervalo de tempo. Duranteo intervalo de tempo inteiro, o mesmo canal será regulado,exceto para o envio de sinais de orientação forçados.
Comentários: O valor máximo de TS_Length pode ser fixadopor regulamentos de espectro de dispersão em alguns países,(por exemplo, 400 ms para o PHY-FHSS-NA-915). 0 comprimentopadrão corresponde a ((Max_Nb_of_Transmitted_Bytes_TS * 8)/ Bit_Rate) + 2 * TS_Margin.
MAC_TS_Margin:
Descrição: A duração de cada intervalo de tempo nasextremidades de um intervalo de tempo quando um ponto finalnão tiver permissão para transmitir. Quando no modo derecepção, o ponto final deve estar ouvindo através dointervalo de tempo inteiro, de modo a se ser capaz decompletar a recepção de uma mensagem vindo de um vizinhocom intervalos de tempo ligeiramente desalinhados.Comentário: 0 valor de TS_Margin depende da pior deriva derelógio entre dois pontos finais e entre duas mensagensrecebidas. Margens mais largas permitirão mais deriva decristal ou mais tempo entre as mensagens, mas diminuirão onúmero máximo de bytes transmitidos por TS e, assim, oritmo de transferência do sistema.
MAC_Tx_Window_max:
Descrição: 0 valor máximo para a janela de randomizaçãousada por um ponto final para a transmissão de seus pacotesde dados.
Comentários: Apenas um pacote deve ser normalmentetransmitido em uma janela de randomização e a posição dopacote nesta janela é randômica. O protocolo não proíbe quepacotes curtos sejam transmitidos na mesma janela, mas istotambém deve seguir as regras de prioridade.
MAC_Tx_Window_min:
Descrição: 0 valor mínimo para a janela de randomizaçãousada por um ponto final para a transmissão de seus pacotesde dados.
MAC_Unsynchronized_Timeout:
Descrição: Duração após a qual um ponto final ainda na fasede descoberta reinicializará sua noção de célula proibida(e o número de fases de descoberta que ele já tentou).
MAC_Wa.rm_Sta.rt_Discovery_Duration:
Descrição: número de fases de descoberta durante a qual umponto final com uma célula preferida tenta se sincronizarcom ela.
Comentários: Este valor deve ser grande o bastante paragarantir uma alta probabilidade de se encontrar a mesmacélula após uma falta, mas pequeno o bastante para nãoatrasar a possível sincronização com uma outra célula, se apreferida não estiver mais disponível. Isto não afeta anoção de célula proibida.
MAC_Xdrift_Filter_A, MAC_Xdrift_Filter_B:
Descrição: Estes são os coeficientes de filtro para umacorreção de deriva de cristal.
Comentários: A modificação destes coeficientes tornará aresposta de degrau de filtração mais lenta ou mais rápida.Uma resposta de degrau mais rápida pode ser desejável paraa aceleração da sincronização de freqüência dos nós.Qualquer modificação destes parâmetros deve ser feitacuidadosamente para se evitar tornar o sistema instável,veja o apêndice relevante.
MAC_Xdrift_Leap TS
Descrição: Este é o intervalo entre os intervalos de tempode pulo. A cada MAC_Xdrift__LeapTS intervalos de tempo, oSACT é carregado com seu valor inicial mais uma pequenacorreção para compensação da deriva do cristal.
Comentários: Valores grandes deste parâmetro aumentarão aresolução da compensação de deriva de cristal, mas tambémaumentarão a importância da correção a ser aplicada a cadaintervalo de tempo de pulo. Valores grandes deMAC_Xdrift_Lea.pTS devem ser usados apenas com bonscristais, de modo a se evitar uma saída de sincronizaçãoentre dois intervalos de tempo de pulo.
MAC_Xdrift_Tmin:
Descrição: Este é o intervalo de tempo mínimo pelo qual ascorreções de relógio precisam ser somadas, antes de um novovalor de correção de deriva de cristal poder ser computado.Comentários: O valor deste parâmetro depende do erro médiofeito quando o relógio (SACT) é ajustado a partir depacotes entrando. Se incertezas no tempo de chegada depacotes forem importantes, este parâmetro deve seraumentado para se calcularem as médias das incertezas.
Dependendo dos regulamentos locais e da banda defreqüência na qual o protocolo opera, os valores padrõesdos parâmetros de MAC mudam. A tabela a seguir proporcionavalores padrões para os parâmetros relacionados à operaçãogeral ou interna da camada de MAC, bem como o gerenciamentode 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 padronizadospara os parâmetros relacionados à fase de descoberta.
<table>table see original document page 134</column></row><table>
A próxima tabela proporciona os valores padronizadospara os parâmetros relacionados à sincronização, escolha depai de sincronização, escolha de célula e gerenciamento detabela 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 facetasde divisão de freqüência e de tempo do presente assunto. Emparticular, o presente assunto de protocolo é baseado em umsistema de salto de freqüência para melhor imunidade àinterferência e para estar de acordo com os regulamentos deespectro de dispersão em alguns países. Na América doNorte, um sistema de salto de freqüência permite umapotência transmitida mais alta do que um sistema usando umúnico canal estreito. Isto significa que freqüência e temposerão divididos. Para o estabelecimento de um enlace de RFentre dois nós, duas condições têm que ser respeitadas, asquais são que duas entidades têm que operar na mesmafreqüência e ao mesmo tempo. 0 protocolo respeita estasduas condições pela adoção de um esquema de intervalo detempo.
O quadro de tempo é dividido pelo presente assunto emintervalos de tempo regulares, cada um deles operando emuma freqüência diferente. Nos Estados Unidos, as regras daFCC (Parte 15.247) especificam que para um sistema de FHSS,o tempo médio de ocupação de qualquer freqüência não deveser maior do que 0,4 s em uma janela de 2 0 segundos. NaEuropa, 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 porcanal na banda de 868 MHz. Dispositivos operando na bandade 868 MHz devem estar em conformidade com um limite deciclo de carga geral que tem a média calculada por todos oscanais usados pelo sistema. Para o presente assunto, aduração de intervalo de tempo foi dimensionada para conteruma única mensagem de tamanho máximo, conforme representadopela Figura 11.
Os regulamentos de FHSS aplicáveis também especificamo número mínimo de freqüências que têm que ser usadas. NaAmérica do Norte, na banda de 915 MHz, se os canais foremde menos de 250 kHz de largura, o número mínimo de canaisserá 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 bandaeuropéia de 2,4 GHz, pelo menos 2 0 canais são requeridos,se uma estratégia de salto de freqüência adaptativo forusada. O salto de freqüência adaptativo permite a seleçãodos melhores canais, para se evitar uma interferência. Poroutro lado, não há um número mínimo de canais na bandaeuropéia de 868 MHz. Quanto mais canais houver no sistema,mais alto o isolamento entre células adjacentes será, masmais 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 precisamentequal canal usar em todo intervalo de tempo. Para se tornaressa operação possível, o uso de canal é organizado deacordo com uma seqüência de salto de freqüência conhecidapor todos os pontos finais pertencentes à rede. Essaseqüência é projetada para uso de todos os canaisigualmente na média.
Para a provisão de isolamento entre célulasadjacentes, cada célula tem sua própria seqüência de saltode freqüência. Essa seqüência pelo presente assunto édescoberta por todos os pontos finais da célula durante oprocesso de sincronização. Para a adição de mais isolamentoentre as células, foi escolhido pelo presente assuntoorganizar o padrão de salto em hiperquadros. Veja também apresente Figura 12 que representa o presente assunto dehardware e seqüência de canal, com base em 15 canais deexemplo, com 10 seqüências básicas. Uma técnica dehiperquadro como essa segue uma hiperseqüência de salto defreqüência construída com várias seqüências de salto defreqüência básicas diferentes, o que torna uma seqüênciamais longa, mas sempre com o mesmo subconjunto de canais. Aseqüência agora é constituída com K diferentes seqüênciasbásicas, o que significaMAC_HF_Length=K*MAC_Number_of_Channels intervalos de tempo.
Essa presente abordagem também adiciona uma melhorimunidade a bloqueadores. Em uma dada célula, todos oshiperquadros preferencialmente são idênticos pelo presenteassunto. Uma vez que o sistema tenha passado através de umhiperquadro, ele repete a mesma seqüência de uma formaperiódica.
Com respeito à presente atribuição de seqüência decanal, pelo presente assunto, todos os pontos finaisconhecem as seqüências de canal diferentes que podem serusadas, mas apenas uma seqüência de canal é usada porcélula. A seqüência de canal é dada pelo arranjo de célula.A seqüência é computada pelo conhecimento do algoritmoespecífico, o qual usa o endereço de C12.22 do relê decélula como uma semente. Para mudança da seqüência de saltoem uma célula, o agente de coleta tem que mudar o endereçodo 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 osrelês de célula não são sincronizados uns com os outros).Ao contrário, pelo presente assunto, um número alto decélulas diferentes pode operar na mesma área, porque elesnã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 nacélula, pelo presente assunto. Esse campo é usado para ageração da seqüência de salto, conforme descrito de outraforma aqui.
Um isolamento de célula é obtido pelo presente assuntopreferencialmente através de seqüências quase ortogonais emuma rede de salto de freqüência. Mais particularmente, deacordo com o presente assunto, duas seqüências pseudo-randômicas embutidas são utilizadas para isolamento decélulas em uma rede de espectro de dispersão de salto defreqüência. A seqüência interna é gerada com uma aritméticade campo de Galois e a seqüência externa é uma seqüência deFibonacci que usa o endereço de célula única como umasemente.
O presente assunto de protocolo é baseado em umespectro de dispersão de salto de freqüência (FHSS) paramelhor imunidade à interferência e conformidade comregulamentos de rádio em alguns países. Em um sistema deFHSS típico, todos os nós saltam sua freqüência de canal deacordo com a mesma seqüência pseudo-randômica, de modo aestarem perfeitamente sincronizados para recepção etransmissão. O padrão de salto de freqüência é a regra queatribui um número de canal a cada intervalo de tempo doprotocolo Aloha com intervalo. Esse padrão é periódico, ese repetirá indefinidamente.
Como é muito difícil manter uma boa sincronização porum número muito grande de nós, o sistema do presenteassunto é vantajosamente dividido em células. Cada célulacontém um número limitado de nós e tem sua própriaseqüência pseudo-randômica para sincronização detransceptor. Pelo presente assunto, todos os nós dentro deuma célula são sincronizados com cada outro, mas as célulasdiferentes não são sincronizadas umas com as outras.
Problemas técnicos dessa abordagem são considerados pelopresente assunto, incluindo como encontrar uma formasimples de gerar uma seqüência pseudo-randômica para cadacélula, e como garantir que estas seqüências sejam únicas eprovejam um isolamento suficiente entre células adjacentes.
0 presente assunto combina o uso de uma aritmética decampo de Galois e seqüências de Fibonacci para a geração deseqüências pseudo-randômicas. A seqüência resultante é acombinação de duas seqüências embutidas. A interna é geradapela aritmética de campo de Galois e a externa é gerada poruma seqüência de Fibonacci usando o endereço de célula comosemente. 0 endereço de célula é único para cada célula elevará a seqüências completamente diferentes para quaisquerduas células adjacentes, mesmo se os endereços diferiremapenas em um.
O que vem a seguir é uma descrição formal do presenteassunto de construção de padrão de salto.
A seqüência de salto interna é construída com um campode Galois de ordem p, onde pé um número primo. Uma adiçãoou multiplicação neste campo é para ser realizada em módulode p. Este campo de Galois é:
GF(p) = {0,1, 2,3, ·-·,p-1}
Em qualquer campo de Galois, podem-se encontrarelementos primitivos. Um elemento é dito como sendoprimitivo se suas potências sucessivas gerarem todos oselementos não nulos do campo. Se α for um elementoprimitivo do campo, o campo poderá ser escrito conforme sesegue:
<formula>formula see original document page 141</formula>
Para a criação da seqüência de salto interna a partirdisto, apenas os elementos não nulos do campo sãoselecionados e uma definição conforme se segue éestabelecida da tupla (p-1) ordenada (1, a, a2, a3, ..., ap~2). O comprimento da seqüência de salto interna (o númerode saltos na seqüência) é igual ao número de canais usadospelo sistema, N = p-1. 0 enlace de RF usará váriasseqüências de salto internas diferentes. Cada uma dessasseqüências será gerada por seu próprio elemento primitivo.Diferentes elementos primitivos são selecionados para ageração de K diferentes seqüências de salto internas. Esseselementos primitivos são (α0, αχ, α2, ..., ακ-ι) .
As seqüências de salto internas são numeradas de 0 aK-I. A k-ésima seqüência de salto é gerada pelo k-ésimoelemento 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 dak-ésima seqüência de salto interna e a* é o elementoprimitivo da k-ésima seqüência de salto interna.
A seqüência de salto externa é pretendida para opresente assunto para a provisão de um padrão de salto oqual é único para cada célula. Para a feitura do padrãoúnico, a seqüência de salto externa é construída com umaseqüência de Fibonacci usando o identificador de célula(Cell Identificator) como uma semente, conforme se segue:
<formula>formula see original document page 142</formula>
Aqui, o identificador de célula é dividido em duaspartes: a mais significativa e a menos significativa. 0inteiro M é o comprimento da seqüência externa. Como umapresente alternativa, qualquer extensão deste processo épossível pelo presente assunto. Por exemplo, pode-sedividir o identificador de célula em quatro partes e usaruma seqüência de Tetranacci, conforme se segue:OHS(η) = Ceil ídentifier(«)3 w = 0,1,2,3
OHS (η) = OHS(n -1) + OHS (n - 2) + OHS (η - 3) + OMS (η -A), n = 4 ,---,M-]
Os elementos da seqüência externa são usados para aseleção de uma seqüência de salto de freqüência interna deN saltos específica. Para essa finalidade, os elementos daseqüência de Fibonacci são computados com um móduloaritmético, de modo a se mapear no conjunto de seqüênciasde salto disponíveis. A partir da seqüência interna e daseqüê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 umelemento primitivo pode ser difícil de implementar em ummicroprocessador, é recomendado pelo presente assuntocomputar a seqüência de salto interna iterativamente. Com oprimeiro salto sempre designado como 1, cada saltosucessivo pode ser facilmente computado a partir do saltoprecedente pela equação a seguir.
<formula>formula see original document page 143</formula>
Esta seqüência de salto interna é muito prontamentecomputada com apenas o conhecimento do salto prévio e donúmero de seqüência de salto. Isto é pretendido pelopresente assunto para ser computado antes de cada salto,evitando-se a necessidade de armazenamento de todas asseqüências de salto possíveis na memória.
0 uso de suas seqüências embutidas pelo presenteassunto vantajosamente melhora a dispersão e a imunidade auma interferência. Também, uma forma simples e iterativa decomputação das seqüências de salto é provida, uma formasimples para isolamento das células é provida, e aimplementação iterativa leva a exigências muito baixas dememó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, asuperseqüência de salto é construída com uma seqüência deFibonacci usando-se o identificador de camada de eletrodoCELL 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 oseguinte:
<formula>formula see original document page 144</formula>
Nessa soma, todas as adições devem ser realizadas emmódulo 16. Cada termo na seqüência então é um inteiro entre0 e 15, conforme se segue:<formula>formula see original document page 145</formula>
O inteiro M é o comprimento da superseqüência. Alguémde conhecimento comum na técnica observará que estaindicação em particular não é uma seqüência de Fibonacci debona fide, porque quatro termos são usados na soma, aoinvés de dois. Alguns autores cunharam o termo Tetranaccipara denominar essa seqüência. A superseqüência de saltoserá:
<formula>formula see original document page 145</formula>
Isto também pode ser escrito como:
<formula>formula see original document page 145</formula>
Os elementos da superseqüência são usados para aseleção de uma seqüência de salto de freqüência básica de Nsaltos específica. Se K = 16, cada elemento da seqüência deFibonacci naturalmente aponta para uma seqüência de salto.Este é o caso para a camada física de PHY-FHSS-NA-915. Semenos de 16 seqüências de salto básicas estiveremdisponíveis, os elementos de seqüência de Fibonacci serãoconvertidos em módulo K inteiros de modo a se mapear noconjunto de seqüências de salto disponíveis, conforme sesegue:
<formula>formula see original document page 145</formula>
Dada a superseqüência de salto:
<formula>formula see original document page 145</formula>
Eo 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:
<formula>formula see original document page 146</formula>
Esta hiperseqüência de M * N saltos se repeteindefinidamente de uma forma periódica. Durante o primeirointervalo de tempo, o transceptor de ponto final usará afreqüência indicada pelo primeiro elemento destahiperseqüência para ambas as atividades de transmissão e derecepção. Para o segundo intervalo de tempo, usará osegundo elemento e assim por diante.
O comprimento da hiperseqüência, M*N, está relacionadoao parâmetro de camada de MAC:
M*N = MAC_HF_Length
Um caso especial vale à pena mencionar. Se oidentificador de célula estiver vazio, isto é, se elecontiver apenas zeros, a superseqüência será uma seqüênciaconstante de zeros. Neste caso, a hiperseqüência se reduzpara a repetição da primeira seqüência de salto básicaconforme se segue:
<formula>formula see original document page 146</formula>
A sucessão de M*N intervalos de tempo usando os canaisproporcionados por esta hiperseqüência é denominada umhiperquadro. A presente Figura 13 ilustra uma presenteestrutura de exemplo de um hiperquadro. 0 índice deseqüência de salto básica é o número de salto em cadaseqüência de salto básica e o índice de superseqüênciaespecifica a posição na superseqüência.
A hiperseqüência do presente assunto foi projetadapara se evitar ter duas células diferentes trabalhando como mesmo padrão de salto, desde que tenham identificadoresde célula diferentes, conforme definido aqui. Como éprovável que duas células adjacentes tenham identificadoresde célula próximos, foi verificado se o algoritmo propostoleva a dois padrões de salto muito diferentes, mesmo se osidentificadores de célula diferirem apenas por um bit.
Estas seqüências, não obstante, não são totalmenteortogonais e algumas colisões são inevitáveis. Deve-se terem mente que os relógios de células adjacentes derivarãocom respeito a cada outro. A conseqüência é que duassuperseqüências que diferem apenas por uma permutaçãocíclica não necessariamente proverão um isolamento decélula de uma forma confiável. A probabilidade de istoacontecer, 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 = 52
O número de seqüências de salto básicas é K = 16, ocomprimento de superseqüência é M = 16 e o comprimento dehiperseqüência é:
M*N = MAC_HF_Length = 52 χ 16 = 832
A presente Figura 14 proporciona os elementos primitivospara as K seqüências de salto básicas para uma modalidadede 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 donúmero de seqüência de salto básica 2. A partir da tabelada Figura 14, o elemento primitivo para o número deseqüência de salto básica 2 é 5. A seqüência será computadapor:
<formula>formula see original document page 148</formula>
O primeiro salto sempre é:
<formula>formula see original document page 148</formula>Esse processo continua até os 52 saltos seremcomputados.
Com referência à condução de comunicações com umacélula adjacente, se a seqüência de salto deve serimplementada por um módulo η multiplicação ou por umatabela de consulta é uma questão de transigência entrevelocidade de computação e memória. Embora a abordagemiterativa tenha sido sugerida acima, qualquer escolha podeser feita pelo usuário, de acordo com o presente assunto,sem se afetarem adversamente os aspectos mais amplos dopresente protocolo em questão.
Há uma situação em que as condições dessa transigênciasão diferentes. Quando um ponto final que se comunicar comum outro ponto final pertencente a uma célula diferente, háuma necessidade de ele ser capaz de rapidamente computar opadrão de salto da nova célula, de modo a se ser capaz deinterromper com a freqüência direita no meio do padrão desalto. Se o processo de multiplicação iterativo for usadonesse caso, ele levará a um número de módulo ρmultiplicações tão grande quanto o número na seqüênciabásica. Se isto for em uma dada instância um encargoexcessivo para o microprocessador, o presente assuntoalternativamente poderá usar um algoritmo de exponenciaçãopor 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úmerode operações proporcional ao algoritmo na base dois donúmero de salto. O ganho no tempo de computação, portanto,é relativamente grande.
O algoritmo de exponenciação por elevação ao quadradoconsiste 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üênciade canal começando a partir da expressão a seguir daseqüência de salto:
<formula>formula see original document page 150</formula>
O exemplo a seguir é com base na computação do númerode canal para o número de salto 33 do número de seqüênciabásico 7 da camada física de PHY-FHSS-NA-915.
A partir da tabela referenciada acima (Figura 14), onúmero de seqüência de salto básica 7 usa o elementoprimitivo 19. Portanto, é computado:
<formula>formula see original document page 150</formula>
Uma primeira aplicação do algoritmo leva a:
<formula>formula see original document page 150</formula>
Agora, realizando-se a primeira elevação ao quadrado:
<formula>formula see original document page 150</formula>
e na etapa seguinte:
<formula>formula see original document page 150</formula>Segunda elevação: 432 = 1849 = 47 (mod53)
<formula>formula see original document page 151</formula>
Terceira elevação: 47 = '2209 = 36 (mod 53)
<formula>formula see original document page 151</formula>
Quarta elevação: 362 =1296 = 24 (mod53)
<formula>formula see original document page 151</formula>
Quinta elevação: 242 = 576 = 46 (mod53)
E uma multiplicação final:
<formula>formula see original document page 151</formula>
Embora o número de canal seja 26, a computação deexemplo em questão foi computada em apenas 6 operações, aoinvés de em 32.
Com referência às posições de mensagem e subintervalosde 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 umapercentagem pequena da duração de intervalo de tempo, e, naoutra extremidade, seriam encontradas mensagens de camadasacima, as quais ocupam um intervalo de tempo completo.
O comprimento de TS foi dimensionado para conter umamensagem do tamanho máximo,MAC_Max_Nb_of_Transmitted_Bytes. Se a camada de APIrequisitar uma mensagem mais longa, o LLC fragmentará estamensagem em pacotes. Obviamente, cada pacote não excederá aMAC_Max_Nb_o f_Transmi 11 ed_Byte s (cabeçalho de PHY epreâmbulo incluídos), conforme também referenciado de outraforma em conjunto com a descrição da camada de LLC.
As mensagens de MAC são as mensagens mais curtas quepodem ser enviadas. Uma vez que a camada física por padrãoestá no modo de recepção, os pacotes podem ser recebidos emum intervalo de tempo em que um pacote foi enviado. Paralimitação do número de colisões dentro de um TS entre ospacotes recebidos e transmitidos, os intervalos de temposão divididos em subintervalos de tempo (Sub_TS) detamanhos iguais (MAC_Sub_TS_Length). Seu tamanho é reguladopara se adaptar na mais longa das mensagens de MAC. Porexemplo, na Figura 15 (que mostra as margens de TS eSubintervalos de tempo), até 6 sinais de orientação apartir de vizinhos diferentes podem ser recebidos em umúnico TS.
O tamanho máximo de uma mensagem que pode se adaptarem um subintervalo de tempo éMax_Nb_of_Transmitted_Bytes_sTS. Se uma mensagem for longademais para se adaptar em um subintervalo de tempo, elausará vários, mas sempre começará no começo de umsubintervalo de tempo, de modo a ocupar um número mínimodeles. Este realmente é o conceito de acesso Aloha comintervalo, o qual é aplicado aqui a uma estrutura desubintervalo de tempo de um intervalo de tempo.
Quando uma mensagem deve ser enviada, a seleção donúmero Sub_TS é randomizada entre o segundo e o último TS,uma parte disso sendo livre de transmissões. Setransmissões não forem permitidas nesta parte do TS, asrecepções o serão.
Estas margens proporcionarão a possibilidade decomunicação entre dois pontos finais que não sejamperfeitamente sincronizados. 0 comprimento destas margens,MAC_TS_Margin, reflete o erro autorizado máximo desincronização no tempo entre duas ressincronizações, nocenário de pior caso (erros máximos de relógio, váriossinais 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 redeopera em uma banda de ISM, em que muitos outros usuáriosocupam o mesmo meio (com as mesmas regras). Assim, aprobabilidade de colisão devido ao ambiente externo tende aser mais alta do que a probabilidade de colisão na rede emquestão em si. É por isso que o algoritmo de Aloha comintervalo é apropriado para o gerenciamento do acesso aomeio. A célula inteira é sincronizada no tempo e nafreqüência (conforme descrito aqui). Quando um ponto finalquer falar, ele apenas empurra sua mensagem para o meio emum intervalo de tempo randômico. 0 destinatário receberá amensagem porque ela é sincronizada e porque, por padrão, umponto final está ouvindo o meio (a camada física, porpadrão, está no modo de recepção). Obviamente, uma colisãoocorre quando dois pontos finais próximos querem falar nomesmo intervalo de tempo, mas isto é resolvido por umarepetição das mensagens, uma repetição gerenciada pelacamada de LLC. Quando se empurram dados no meio, a camadade MAC não se importa se é uma mensagem de enlaceascendente ou de enlace descendente; a taxa de bit e todosos 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 igualmenterepresentados e devido ao fato de dados poderem serempurrados para qualquer intervalo de tempo, o presenteassunto de protocolo respeita a ocupação uniforme do meiopela banda.
É muito importante que o tráfego permaneça muitobaixo, para se garantir um bom funcionamento do acesso deAloha com intervalo. O Aloha com intervalo permitirá até25% de carga de dados, se a rede em questão estivessesozinha no meio. Em uma situação de vida real, 3% de cargade dados são mais adequados.
A cada vez em que um pacote é recebido a partir de umvizinho, a camada física torna disponível uma leitura deRSSI para aquele pacote. Para cada vizinho em sua tabela devizinho, a camada de MAC computará um valor médio desteRSSI com um filtro de Kalman. Este filtro proporcionará umaestimativa acurada do RSSI médio tão logo umas poucasleituras de RSSI estejam disponíveis. 0 pseudocódigo aseguir 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 aquelepacote
RSSI_Cov = 255
Else (Caso contrário) computar o novo RSSI_Average com(01 d RSSl Cov)
<formula>formula see original document page 154</formula>
Novo RSSI_Average = (I-KG)(Antigo RSSI_Average) +KGdeitura 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 deRSSI_Average e o novo valor de RSSI_Cov.
RSSI_Cov é a estimativa da covariância do RSSI, temque ser mantida na memória para cada vizinho, bem como oRSSI médio, RSSI_Average. RSSI_Var é um parâmetro de camadade MAC que corresponde a uma estimativa da variância deRSSI. RSSI e RSSI_Average são variáveis codificadas de doiscomplementos de 1 byte. Sua faixa se estende a partir de -128 dBm a +127 dBm. RSSI_Cov é uma variável positiva de 1byte. KG é o ganho de Kalman, é um resultado intermediáriona computação do filtro de Kalman e é um valor sempre menordo que um.
O RSSI médio proporciona uma indicação razoável daqualidade do sinal recebido, mesmo em ambientescontaminados com um desvanecimento de Rayleigh. Conformeexplicado em uma outra seção deste documento, este RSSImédio participa na escolha do melhor pai de sincronização.
É tarefa da camada de MAC atualizar o LPD (atraso depropagação médio local) associado a cada vizinho e computaro GPD (atraso de propagação médio global) a partir do pontofinal até o relê de célula através de cada vizinho. Estesvalores são usados para a classificação e a seleção devizinhos. Eles são usados para a seleção do melhor acessopara sincronização ou para a feitura de uma escolha entrediferentes células disponíveis. A camada de rede usaráestes valores para escolher o melhor caminho para um enlaceascendente (roteamento de pacotes).
Após toda transmissão de pacote que requer umreconhecimento, a camada de MAC saberá se a transmissão depacote foi bem sucedida ou não. Se um reconhecimentopositivo ou negativo for recebido, a transmissão seráconsiderada bem sucedida. Se nenhum reconhecimento forrecebido, a transmissão será considerada como tendofalhado. Se nenhum reconhecimento for recebido, atransmissão será considerada como tendo falhado. Para cadavizinho 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>
Se a transmissão foi
<formula>formula see original document page 156</formula>
Nestas equações, o parâmetro de MAC MAC_LPD_NAVG é umvalor inteiro que determina a profundidade da janela médiadeslizante. Um fator de escalonamento de 16 foi introduzidopara se permitir uma representação de inteiro de LPD. 0valor máximo admitido para LPD é LPD_Max, qualquer valor deLPD calculado acima de LPD_Max devendo ser truncado paraLPD_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 novoLPD eqüivaler a um antigo e tiver havido uma falha, o novoLPD deverá ser incrementado por um; se tiver havido umsucesso de transmissão, então, o LPD deverá serdecrementado em um.
O GPD (atraso de propagação médio global) é o atrasode propagação médio entre o ponto final e seu relê decélula associado. A rede computará este valor etapa poretapa a partir do relê de célula até o ponto final. Para seevitar uma confusão, pode-se considerar a notação a seguir:EP_GPD(X) ξ atraso de propagação global entre o pontofinal e o mestre de célula se um tráfego for roteadoatravés do vizinho X.
Um ponto final pode computar o GPD para o relê decélula através de um de seus vizinhos de acordo com a
EP_GPD (X) == GPD de vizinho X + LPD entre o ponto finale o vizinho X + MAC_GPD_TD
MAC_GPD_TD é um parâmetro de camada de MAC introduzidopara modelagem do atraso de propagação fixo através de cadanó da rede (veja o apêndice sobre o algoritmo de seleção depercurso). 0 melhor destes valores será denominado o GPD deponto final.
GPD = Min { EP_GPD(X) } para todos os vizinhos X que forempais registrados.
Este valor de GPD será incluído no cabeçalho de MACpara se tornar esta informação disponível para outrospontos finais. Os valores admitidos para GPD são osinteiros entre zero e 4095.
0 nó deve atualizar seu GPD quando ele mudar de nívelou comutar para uma outra célula. 0 ponto final tambémprecisa checar se seu GPD ainda não mudou em cada recepçãode uma mensagem a partir de um de seus pais. Em uma visãomais geral, um ponto final sempre deve manter o GPD maisbaixo que puder, dentre seus pais registrados (a partir damesma célula).
Na partida, os valores de LPD na lista de vizinhodevem ser inicializados de acordo com o valor de RSSI daprimeira mensagem recebida a partir destes vizinhos. Ainicialização segue esta regra:
<formula>formula see original document page 158</formula>
Dito de uma outra forma, o presente assunto deprotocolo prove vantajosamente um roteamento de enlaceascendente, sem requerer uma tabela de roteamento. Isso éobtido pelo endereçamento do principal percurso de enlaceascendente na rede em questão. Essa comunicação é usadapara o transporte dos dados, a partir de todo nó da redepara um ponto de extração único. 0 desafio associado a esserecurso e presentemente obtido é para um nó para encontraro percurso em direção ao ponto de extração, sem oconhecimento da topologia de rede, isto é, sem uma tabelade roteamento. Seguindo-se ao objetivo de atingir o pontode extração em um tempo mais curto, o tráfego deve serrelativamente disperso, de modo a se evitarem picos,conforme o tráfego se tornar mais denso próximo do ponto deextração.
Conceitualmente, pelo presente assunto, o processo desincronização proporcionou um nível a todo nó na rede. Essenível representa o número de saltos entre o nó e o ponto deextração. Cada nó tem um certo número de vizinhos em umní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 deextração) denominados filhos.
De acordo com o presente assunto, um nópreferencialmente deve propagar uma mensagem de enlaceascendente para um de seus pais, o que significa um nó maispróximo da parte visível da rede. A mensagem no fimconverge no ponto de extração. 0 pai selecionado pararoteamento de uma mensagem de enlace ascendente pertence àlista de melhor pai. Pais pertencentes a essa lista sãoaqueles com o melhor GPD. A computação do atraso depropagação global, GPD, de outra forma é explicada aqui. OGPD mais baixo indica o percurso mais curto no tempo. 0 paiselecionado não necessariamente sempre é aquele com omelhor GPD. O nó envia mensagens de enlace ascendenterandomicamente para um destes melhores pais com umaprobabilidade de cada pai inversamente proporcional a seu GPD.
Vantajosamente, a prática desses aspectos do presenteassunto obtém os benefícios de os percursos mais curtosserem selecionados, um conhecimento concernente apenas avizinhos a um salto é suficiente para a obtenção, os nósnão precisam de um conhecimento da rede inteira, de modoque não haja uma tabela de roteamento nos nós, o queresulta em economias relativamente grandes na memóriarequerida. Além disso, falando geralmente, o tráfego édisperso pela rede, devido à randomização entre os pais.
Um aspecto do presente assunto de protocolovantajosamente prove uma distribuição e uma recuperação derelógio em tempo real, particularmente aplicável a umarede, por exemplo, de outra forma com base no protocoloAloha com intervalo.Falando geralmente, o tempo é presentemente divididoem intervalos de tempo (TS) e os nós enviam pacotes dentrodesses intervalos de tempo. A freqüência usada paracomunicação muda em cada TS de acordo com um padrãopredeterminado: o hiperquadro. Um número, o número deintervalo de tempo (TSN), é incrementado em cada TS e rolaquando atinge o comprimento de hardware, em cujo ponto opadrão de freqüência se repete. Um segundo número, o númerode hiperquadro (HFN), também é associado e incrementado comcada hiperquadro.
Os nós são agrupados em uma célula em torno de umconcentrador (ou nó de raiz) e estes 2 números são comuns atodos os nós na célula; desta forma, seus transmissoressempre estão regulados na mesma freqüência de RF. Estes 2números serão usados pelos nós para a atualização de seurelógio "de tempo real", mediante o recebimento de umamensagem especifica, a qual se origina a partir do nó deraiz. Efetivamente, a distribuição do relógio será feita apartir do nó de raiz (ponto de extração dos dados de nós) ,o qual é conectado à internet e, assim, tem acesso a umrelógio em tempo real acurado (por exemplo, no padrão NTP).
Geralmente, os nós operam com cristais, o que resultaem uma acurácia limitada. 0 presente desafio, o qual éendereçado de forma bem sucedida aqui é atualizarperiodicamente o tempo em cada nó, antes de seu relógioderivar além da acurácia desejada. Uma vez que a propagaçãonão é instantânea, o sistema tem que levar em consideraçãoo atraso de propagação.
A presente solução é difundir vantajosamente umaestampa de tempo (RITP) provida pelo relógio de tempo realescolhido. A criação da estampa de tempo sempre será feitano nível de nó de raiz, quando o TSN e O HFN da célulaforem ambos nulos. Esta difusão também conterá o número dehiperquadro (HFN) correspondente à difusão inicial pelo nóde raiz; isto permitirá a detecção de um estouro para maisde 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 é projetadopara a rolagem ser muito além do atraso de propagaçãomáximo desta distribuição de relógio em tempo real.
Quando um nó recebe esta difusão, ele pode atualizarseu relógio de "tempo real" usando a fórmula a seguir:
Tempo absoluto = (TSN + HFN * hyperframe_length) *TimeslotLength + RITP
onde o comprimento de hiperquadro é expresso em número deintervalos de tempo e o comprimento de intervalo de tempo éuma unidade de tempo (note 150 ms no presente caso deexemplo). Nota: se o HFN de recepção for mais baixo do queo HFN incluído na difusão, então, houve uma rolagem e aestampa de tempo RITP deve ser atualizada pela adição devalor de rolagem de HFN * hyperframe_length *Timeslot_Length. Essa presente solução proporciona um tempoabsoluto com uma resolução igual ao comprimento deintervalo de tempo.
Quando um nó apenas se sincroniza em uma nova rede, aestampa de tempo RITP (e o HFN correspondente) éproporcionada no reconhecimento de sincronização. Destaforma, o novo nó tem acesso ao tempo real sem esperar pelapróxima difusão de ITP. Nota: isto assume que a difusão deRITP é feita a cada vez em que HFN = TSN = 0, para seevitar mais de uma rolagem do número HFN.
Esses aspectos do presente assunto de protocolovantajosamente provêem uma forma simples, mesmo usando-seuma arquitetura de Aloha com intervalo, para a distribuiçãode um relógio de tempo real para todos os nós com umaresolução de um intervalo de tempo (apesar do atraso depropagação). Eles também permitem uma recuperação rápida dorelógio de tempo real imediatamente mediante umasincronização para uma nova rede.
Portanto, pelo presente assunto, um gerenciador detempo na camada de MAC é realizado com o uso de várioscontadores. A Figura 16 ilustra a estrutura global dessespresentes contadores de estrutura de manutenção de tempo deprotocolo, enquanto o que vem a seguir provê algumadescrição adicional para cada um desses contadores.
Quanto ao temporizador de contagem de Aloha comintervalo (SACT) no começo de cada intervalo de tempo essetemporizador é carregado com um valor correspondente aocomprimento de intervalo de tempo padrão, MAC_TS_Length.
Quanto este temporizador atinge o valor zero, um novointervalo de tempo começa. A cada MAC_Xdrift_LeapTSintervalos de tempo, o SACT é carregado com o valor deMAC_TS_Length mais uma pequena correção para compensação daderiva do cristal (veja a descrição de intervalos de tempode pulo no capitulo de correção de deriva).
0 SACT é localmente implementado com uma resoluçãoespecificada pelo parâmetro MAC_FW_Accuracy, mas quando osvalores de SACT são trocados entre os pontos finais ouincluídos no cabeçalho de MAC para fins de sincronização, oSACT é definido como uma resolução de MAC SACT Resolutionps.
O conteúdo do contador de intervalo de tempo é onúmero de intervalo de tempo (TSN) . No começo de cadaintervalo de tempo, este contador é incrementado. Seu valorvai de zero a MAC_HF_Length -1. MAC_HF_Length é o número deintervalos de tempo em um hiperquadro.
O contador de intervalo de tempo pode ser dividido emdois contadores em cascata, o contador de seqüência desalto básica e o contador de superseqüência. O conteúdo docontador de seqüência de salto básica indica a posição emuma seqüência de salto básica. No começo de cada intervalode tempo, este contador é incrementado. Seu valor vai dezero 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çãona superseqüência de salto. Quando uma seqüência de saltobásica é completada, este contador é incrementado. Seuvalor vai de ze ro 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 umainformação de tempo absoluto seja obtida a partir da redeou da aplicação, este contador pode ser atualizado. Em cadaestouro para cima do contador de hiperquadro, a estampa detempo de ITP relativa deve ser atualizada, conformeexplicado em outro lugar aqui. Esta estampa de tempo podeser implementada com o formato de NTP (Protocolo de Tempode Rede) padrão ou com uma versão resumida do formato deNTP padrão, de acordo com a acurácia requerida e com afaixa.A presente Figura 17 geralmente representa um formatode estampa de tempo de ITP (Protocolo de Tempo Itron)padrão. A partir da estrutura de gerenciamento de tempo deprotocolo presente referenciada acima, podem-se definirvários valores de tempo. Dois desses dados aqui serão úteispara várias finalidades, e eles são o tempo absoluto e otempo relativo.
0 tempo absoluto corresponde ao relógio de tempo realda aplicação. Ele pode ser usado para datar qualquer eventode uma forma absoluta. Sua resolução é o comprimento deintervalo de tempo. Em termos de contadores de manutençãode tempo, o valor de tempo absoluto é dado pela fórmula járeferenciada aqui acima.
Em contraste, o tempo relativo usado para medição dasdurações em uma escala de tempo menor do que a faixa dorelógio de MAC. Este tempo tem uma resolução mais alta,porque usa o SACT. Em termos de contadores de manutenção detempo, o valor de tempo relativo é dado por:
Tempo relativo = (TS_Length - SACT * "unidades de tempo deSACT") + (TSN + HFN * MAC_HF_Length) * TSJLength
As unidades de tempo de SACT dependem daimplementação e são dadas pelos parâmetros MAC_FW_Accuracyou 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 derelógio de MAC)
Uma operação de geração de uma estampa de tempoabsoluta é necessária quando a camada de MAC tem queinformar à camada de LLC que um novo valor de relógio detempo real foi entregue pela rede. O valor de estampa detempo computado nessa instância é o tempo absoluto nomomento em que a camada de MAC envia para as camadassuperiores a indicação da chegada da nova estampa de tempo,conforme se segue:
Estampa de tempo de ITP absoluta = (TSN + HFN *MAC_HF_Length) * MAC_TS_Length + RITP
Com relação à geração de um valor para a estampa detempo de ITP relativa, quando a aplicação comunica um valorde estampa de tempo de ITP para a camada de MAC, a camadade MAC precisará referenciar esta estampa de tempo para orelógio de MAC (TSN e HFN) e armazenará o valor resultanteem seu registrador de estampa de tempo de TIP relativa.
Isto correrá, por exemplo, em um relê de célula, quando aaplicação precisará ajustar os relógios de tempo real dacélula. O valor de RITP será computado com a equação aseguir:
RITP = (valor de estampa de tempo de ITP) - (TSN + HFN *MAC_HF_Length) * MAC_TS_Length
Com relação ao presente assunto de protocolo deServiços de Sincronização de Tempo, há duas formas depropagação do tempo ao longo de uma célula inteira: em umafase de sincronização e por uma atualização periódica. 0presente assunto de tempo absoluto será usado dentro dopresente assunto de protocolo de rede em si (na camada deMAC) e no nivel de aplicação (neste exemplo, medição deenergia).
Cada relê de célula tem um cliente de NTP o qualpermite que ele receba uma estampa de tempo de NTP a partirda WAN. Ele usa seu valor de NTP para a atualização de suaRITP. 0 relê de célula envia periodicamente mensagens dedifusão de ITP para a célula inteira, com exatamente omesmo processo como uma mensagem de difusão "regular". Suamensagem de difusão de ITP contém a informação de RITP,base da regeneração de tempo em pontos finais. A cada vezem que um EP recebe uma mensagem como essa, ele lê eatualiza 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 despertaapós uma falha de potência, ele não tem mais qualquer noçãode tempo. O campo de RITP é dado dentro de uma mensagemSYNC ACK após o EP requisitar uma sincronização com umvizinho sincronizado. Assim, tão logo um EP sejasincronizado, vantajosamente ele conhece o tempo pelopresente assunto de protocolo.
Em um aspecto do presente assunto, um objetivovantajosamente alcançado é ajustar os relógios de temporeal em todo nó de uma célula. Não há um argumento deentrada requisitado. A operação é descrita no contexto deum serviço que é usado apenas em um relê de célula. Acamada de MAC de relê de célula constrói um pacote dedifusão de ITP. O cabeçalho de MAC deste pacote contém ovalor da RITP em conjunto com o HFN no momento em que opacote é criado. Este pacote é difundido com as regras dedifusão usuais definidas neste protocolo. Esta difusãopermitirá que cada nó destinatário atualize sua própriaestampa de tempo de ITP relativa. Os nós destinatáriosusarão o valor de HFN incluído no pacote para a detecção deum possível estouro para cima do relógio de MAC, desde acriação do pacote de difusão de ITP. A faixa de relógio demembro de carne deve ser muito mais longa do que o tempo depercurso esperado de um pacote através da rede de malha, demodo a se evitarem ambigüidades.
Em um outro aspecto do presente assunto, um objetivovantajosamente alcançado é a provisão de um serviço o qualpermite que a camada de aplicação (através de LLC e NET)atualize a estampa de tempo de ITP relativa da camada deMAC. 0 argumento de entrada requisitado envolve a estampade tempo de ITP absoluta. A operação de novo é descrita nocontexto de um serviço que é usado apenas em um relê decélula. A camada de MAC usa a estampa de tempo de ITPabsoluta para computação de um valor de estampa de tempo deITP relativa. A camada de MAC então atualiza seuregistrador de RITP com seu valor computado (veja "Geraçãode um valor para a estampa de tempo de ITP relativa"acima). Este serviço usualmente é chamado antes de umadifusão de ITP. É distinto do serviço de difusão de ITP, demodo a se evitar um envelhecimento descontrolado de umaestampa de tempo em um pacote esperando em uma fila.
Ainda um outro aspecto do presente assunto é aobtenção vantajosa de um objeto de indicar para a camada deaplicação (através de LLC e NET) que uma difusão de ITP foirecebida. Os argumentos de saída requisitados são a estampade tempo de ITP absoluta, a RITP, e valores de HFN a partirdo cabeçalho de MAC. Então, ela compara o valor de HFN nocabeçalho de mensagem com seu próprio HFN. Isto permite quea camada de MAC detecte ura possível estouro para cima docontador de hiperquadro, desde a criação do pacote dedifusão de ITP. Se nenhum estouro para cima de HFC tiverocorrido, ela escreverá o valor de RITP em seu próprioregistrador de RITP. Se um estouro para cima tiverocorrido, ela incrementará o valor de RITP com a faixa dorelógio de MAC e escreverá o resultado em seu registradorde RITP. A camada de MAC então computa uma estampa de tempode ITP absoluta (veja "Geração de uma estampa de tempoabsoluta" acima) e envia para a camada de LLC uma indicaçãocom esta estampa de tempo de ITP absoluta como argumento.
Esta indicação informa à camada de LLC que a RITP foiatualizada na camada de MAC e proporciona à camada de LLC ovalor de uma estampa de tempo que pode ser usada para aatualização do relógio de tempo real da aplicação. 0 pacotede difusão de ITP então é encaminhado para os filhos deponto final de acordo com as regras de difusão usuais. Osvalores de RITP e HFN recuperados a partir do cabeçalho deMAC de pacote de difusão de ITP também são enviados para acamada de LLC com a finalidade de permitir a reconstruçãodo pacote para o acompanhamento da difusão.
Um outro objetivo vantajosamente alcançado com opresente protocolo em questão permite que um ponto finalobtenha o valor da RITP e o valor do contador dehiperquadro a partir de seu pai na sincronização. Essaoperação usualmente é uma parte do processo desincronização, conforme discutido de outra forma aqui.
Contudo, em nome da presente clareza, é simplesmente notadoque quando um ponto final recebe um reconhecimento para suarequisição de sincronização, ele atualizará sua RITP e seuHFN a partir da informação contida naquele reconhecimento.
Um aspecto importante em uma rede de malha usando umaseqüência de salto de freqüência é o processo desincronização. De fato, uma vez que todo EP na célulaconhece a seqüência de canal e o TS atual na seqüência,eles precisarão periodicamente manter essa informaçãoatualizada. Devido à deriva de relógio, essa informaçãopode se tornar corrompida com o tempo. Uma ressincronizaçãodo relógio de todo EP, portanto, é necessária.
Quando a rede em questão é comutada para ligada pelaprimeira vez, nenhum componente conhece o começo deintervalos de tempo e qual freqüência usar. Como em todosos sistemas sincronizados, um metrônomo ou uma operaçãoequivalente é necessário. 0 relê de célula (ou mestre decélula) é o componente preferido no presente assunto deprotocolo, porque sempre é considerado como "sincronizado".
Para os outros pontos finais, pelo presente assunto, asincronização é hierárquica. Os pontos finais os quaispodem ouvir o relê (mestre de célula) se tornamsincronizados e, então, é a sua vez de sincronizar seusvizinhos. Durante esse processo, um nivel é dado a cadaponto final, o qual indica a quantos saltos eles estão dorelê de célula (mestre de célula).
Um relê tem um nivel "1" ; um ponto final nãosincronizado tem um nivel "0"; e um ponto final que estejaa N saltos do relê de célula tem um nivel "N+l" . Osrespectivos níveis relativos ao presente protocolo desincronização são representados na presente Figura 18.
Para resumir a terminologia referenciada de outraforma aqui, um ponto final o qual é de:• Nível N se comparado a um nível de EP de N-x,χ>=1, é denominado um filho (ou criança)
• Nível N se comparado a um nível de EP de N+x,x> = l, é 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 desincronização de hierarquia do presente assunto, de modoque um ponto final mantenha sua sincronização a partir dequalquer vizinho sincronizado que respeite as condições aseguir:
• O vizinho deve pertencer à mesma célula (mesmaseqüência de canal)
· O vizinho deve ser um pai, isto é, deve ter umaposição hierárquica mais alta (um número de nível maisbaixo).
Essas condições proporcionam a possibilidade de um pontofinal ter mais de uma fonte para informação desincronização. Isto é possível porque, no fim, todo mundona célula terá a mesma base de tempo. Isto também permiteque um ponto final de nível N se sincronize com um pontofinal de nível N-2 (veja as condições para mudança de nívelreferenciadas de outra forma aqui).
O nível máximo em uma célula é de 63. Ele é limitadopelo número de bits (6) alocado a este campo nas mensagens.Como resultado das regras acima, um EP de nível 63 não podeser usado para sincronização.
A presente Figura 20 representa vários aspectos dopresente assunto de protocolo conforme se refere a umaressincronização entre pontos finais (EPs). Pelo presenteassunto, um EP vantajosamente se ressincroniza a cada vezem que recebe uma mensagem de um de seus pais, aorecomputar o começo de seu próximo intervalo de tempo. Emcada começo de cada intervalo de tempo, um temporizador decontagem regressiva denominado Temporizador de ContagemRegressiva de Aloha com Intervalo, SACT, é regulado com ovalor MAC_TS_Length. Quando esse temporizador atinge 0, acamada de MAC comuta para o próximo intervalo de tempo. 0processo de ressincronização consiste na recomputação dovalor do SACT para alinhamento dos intervalos de tempo dosfilhos naqueles dos pais. Esta ressincronização é realizadacom 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 prontamentecomputada.
• No lado de transmissor, o remetente indica nocabeçalho de MAC o valor de SACT, SACTlO,correspondente ao começo da transmissão física dopacote (isto é, o tempo entre a transmissão doprimeiro bit do pacote e a próxima mudança deintervalo de tempo, conforme medido em unidades detempo de SACT).
No lado de receptor, assim que o SFD é detectado, acamada física do ponto final destinatário lê seu valorde temporizador, SACT20, e deduz SACT20+dl, o valor deSACT quando o remetente começou a transmissão de suamensagem.
A camada física indica para a camada de MAC querecebeu uma mensagem em SACT20+dl. A camada de MACtambém lê o valor de temporizador SACTlO contido nocabeçalho de MAC.
• Então, em qualquer momento, a camada de MAC podeatualizar seu valor de temporizador, SACT2, pelacorreção adicionada ASACT.
SACT '2 = SA CT 2 + ASACTASACT * SACTlO-(SACT2Q + dí)
Vantajosamente, pelas presentes operações, o pontofinal se auto-ajusta ao próximo intervalo de tempo, o quecompensa a deriva interna do dispositivo. Ao seguir essepresente processo em cada mensagem recebida a partir de umponto final de nível mais alto, o ponto final drasticamentediminui a probabilidade de perder sua sincronização.
A cada vez em que um ponto final recebe uma mensagemde um ponto final vizinho, a camada de MAC grava doisvalores de tempo na tabela de vizinho: o valor de SACT lidoa partir do cabeçalho de MAC de remetente (SACT10 acima) eo tempo de recepção do pacote. Estes valores então podemser usados em qualquer momento quando o ponto final decidirse sincronizar com aquele vizinho.
O SACT é definido com uma resolução deMAC_SACT_Resolution ps.
Uma datação de mensagens recebidas e transmitidas deveser acurada o bastante para permitir que o presenteprotocolo funcione apropriadamente e, especificamente, parao processo de ressincronização funcionar corretamente. 0relógio de cristal do sistema deve se escolhido em ±MAC_Crystal_Accuracy ppm e o firmware tem que datar amensagem em ± MAC_FW_Accuracy ps. A datação de uma mensagemrecebida deve ser feita pela tomada de um instantâneo dotemporizador de contagem regressiva SACT quando o campo deSFD for detectado pela camada PHY, conforme é explicado deoutra forma aqui.
Um remetente também deve datar a mensagem e incluir ovalor de SACT no cabeçalho de MAC. É uma tarefa difícilcomputar precisamente o SACT no momento exato em que acamada PHY enviará o último bit. De fato, nesse ínterim, acamada de MAC terá que construir o cabeçalho, computar aCRC e, então, proporcionar a mensagem para a camada PHY; e,então, a camada PHY terá que adicionar seu cabeçalho econfigurar o transmissor de RF. É um aspecto do presenteassunto que seja preferível para uma dada implementação domesmo (tal como na produção do firmware real a ser usado)estimar um tempo de pior caso entre o momento da datação ea transmissão planejada, e regular um temporizador com essetempo. Durante essa alocação de tempo, as camadas de MAC ePHY devem ter tempo suficiente para preparação do pacote. Acamada PHY então esperará durante o tempo remanescente eenviará o primeiro bit assim que o temporizador atingir ovalor definido.
Para uma implementação em particular usando umaabordagem de transceptor produzido em série, é notado queuma datação da recepção de SFD tipicamente é a coisa maissimples e preferida a fazer. Se for mais conveniente parauma dada implementação datar em um outro momento dentro damensagem, o usuário estará livre para fazê-lo pelo presenteassunto, desde que se lembre de levar em consideração ocomprimento da mensagem.
Quando um ponto final recebe uma mensagem, ele podecomputar facilmente o começo do próximo intervalo de tempo.Mas essa informação sozinha não é suficiente, uma vez que ocanal no próximo intervalo de tempo não é conhecido naquelemomento. 0 ponto final encontrará esta informação nocabeçalho de MAC. Três campos são importantes para oprocesso de sincronização. 0 primeiro é o nível doremetente: uma (re)sincronização é permitida apenas com ospais. Os dois outros campos são o número de intervalo detempo e o endereço de célula. Como todo ponto final podecomputar a seqüência de canal a partir do endereço decélula contido no cabeçalho, e devido ao fato de o númerode intervalo de tempo informar onde o remetente está nahiperseqüência, o destinatário pode encontrar o canal que oremetente usará no próximo intervalo de tempo.
Esses três campos estão presentes em todas asmensagens: sinais de orientação ou outras mensagens. Assim,toda mensagem pode ser usada para sincronização. 0 campo denúmero de intervalo de tempo tem um outro uso. Mesmo se umponto final receber uma mensagem em um canal adjacente, elesaberá o canal real no qual a mensagem foi enviada.
Um EP se ressincroniza a cada vez em que recebe umamensagem de um pai de SYNC, qualquer que seja a natureza damensagem. Se não houver um tráfego, mensagens dedicadas(presentemente referido como sinais de orientação) sãoenviadas periodicamente por todo EP sincronizado. Se otráfego for denso o bastante, se comparado com aperiodicidade de sinal de orientação padrão, os sinais deorientação não serão enviados. Pode ser visto como umtemporizador com o valor inicialMAC_Beacon_Periodicity_SYNC. A cada vez em que um pacote éenviado, o temporizador é reiniciado a partir do começo. Seo temporizador atingir 4O', um sinal de orientação seráenviado.
Vários parâmetros permitem a computação de umaperiodicidade 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 (ouoscilador) e do relógio de firmware. Um outro parâmetro é onúmero de sinais de orientação que se pode assumir que umsistema possa perder, devido a colisões, emperramentos,etc. O último parâmetro é a deriva máxima que o sistemaestá autorizado a ter entre 2 níveis. Para essa computação,pode-se considerar o pior caso, quando o EP tem apenas umpai SYNC.
<formula>formula see original document page 175</formula>
Exemplo:
TS_Margin = 15 msClock_Accuracy = ±2 0 ppmMax_Nb_of_Missed_Beacons = 3 sinais de orientação perdidosTS_Length = 15 0 ms
-> Beacon_Periodicity_SYNC = 625 TS (isto corresponde a 1min 34 s)
Em uma situação de tráfego baixo com muitos pontosfinais transmitindo sinais de orientação periódicos, há umaprobabilidade significativa de dois pontos finaisescolherem o mesmo intervalo de tempo e subintervalo detempo para transmissão de seus sinais de orientação. Estaprobabilidade aumenta aproximadamente conforme o quadradodo número de pontos finais e estaria próximo de um em umagrupamento de 100 pontos finais. Isto levaria a colisõesrecorrentes entre aqueles sinais de orientação. Para seevitar esta situação, o tempo de transmissão real dossinais de orientação deve ser randomizado em +20%, isto é,uma janela de em torno de 125 intervalos de tempo (paraMAC_Beacon_Period_SYNC = 625) , enquanto se mantém aperiodicidade média definida acima.
O indicador de tamanho de célula, CSI, é um campo de 4bits contido em cada camada de MAC. Este valor de campo éregulado pelo mestre de célula, dependendo do tamanho dacélula (determinado pelo número de entradas em uma tabelade roteamento de mestre de célula de NET). Isto requereráuma mensagem interna a partir da camada de NET do mestre decélula para sua camada de MAC. Este campo, como o GPD,propagar-se-á com cada mensagem do mestre de célula. Emcada mensagem recebida de um de seus pais, ou de pontosfinais os quais foram pais, o nó atualiza seu CSI olhandopara o valor de cabeçalho de MAC. Um ponto final (outroalém do mestre de célula) sempre mantém o valor mais altode CSI dentre seus pais pertencentes à mesma célula.
Os algoritmos para se escolher uma célula durante umafase de descoberta e comutar a célula consistirão naseleção do melhor pai de acordo com seu termo. O CSI é umdos parâmetros usados para a determinação deste termo. Osvalores para o CSI são dados na seção de camada de rede.
Alternativamente, pelo presente assunto, a propagaçãode CSI deve ser com base na última mensagem recebida apartir de um pai. Essa abordagem evita manter este campoextra na tabela de vizinho de cada EP. A transigência é quedurante a propagação de um novo valor de CSI, haverá muitomais rebotes (ao contrário torna mais rápido aumentar ovalor e desacelerar para diminuí-lo).
Um vizinho de um ponto final é chamado um pai desincronização potencial (ou pai de SYNC potencial) paraaquele ponto final, se ele estiver em conformidade comtodas as condições a seguir:
• O vizinho é conhecido pelo ponto final, isto é, elefoi ouvido pelo menos uma vez e ainda está gravado natabela de vizinho.
O vizinho já está sincronizado (seu nível é diferentede zero).
• O vizinho tem um nível abaixo de 63 (o qual é o nívelmáximo admitido em uma célula).
• O vizinho é registrado em uma célula (bit de RS = 1).
O vizinho é um ponto final autorizado, isto é, umponto final que não foi marcado com um indicador tipode flag como proibido (o bit Sync_Forbidden na tabelade vizinho deve ser zero).
• 0 vizinho tem pelo menos uma conectividade fraca. Graude 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 valormá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 é reguladopela camada de API. Ele pode ser regulado se o usuáriodecidir que duas células próximas nunca devem autorizarpontos finais a partir da outra célula ou se uma célulaestiver cheia. Uma célula pode ser reautorizada pela camadade API. Esta informação também será reinicializada se omedidor ficar não sincronizado por um tempo longo, definidopelo parâmetro MAC_Unsynchronized_Timeout.
Através de um processo de seleção descrito mais tarde,o pai de sincronização potencial mais adequado é escolhidopara se tornar o pai de sincronização (ou pai de SYNC pararesumir). Se este vizinho responder positivamente àrequisição de sincronização, ele se tornará o pai de SYNCreal do nó.
Deve ser destacado que as condições de pai de SYNCpotencial são avaliadas em um dado tempo. Se um pai de SYNCpotencial (ou um pai de SYNC) não for ouvido durante oMAC_Neighbor_Timeout, ele será removido da tabela devizinho de MAC e não será mais considerado um pai de SYNCpotencial (ou pai de SYNC).
Quando um ponto final se torna sincronizado com umacélula, parte de seus pais potenciais será de pais reais ealguns outros poderiam ser irmãos ou filhos. Por outrolado, alguns pais poderiam não se qualificar para serempais de SYNC potenciais. Os pais que também são pais deSYNC potenciais serão chamados pais saudáveis. Obviamente,por definição, um ponto final não sincronizado não tem paialgum, ele podendo ter apenas pais de SYNC potenciais. AFigura 2IA representa esquematicamente pais de SYNCpotenciais e pais saudáveis para um nó sincronizado.
0 grau de conectividade (CD) é uma variável que mede aconectividade de um nó com a rede. 0 grau de conectividadepelo presente assunto é representado pela presente Figura21B. 0 valor de CD de um nó depende apenas do número depais de SYNC potenciais que ele tem dentre seus vizinhos.Se o ponto final ainda não tiver sido sincronizado, todosos pais de SYNC potenciais serão considerados para acomputação de CD. Por outro lado, se o ponto final forsincronizado, apenas os pais e filhos serão levados emconsideração. Note que um ponto final sincronizado deve terpelo menos um pai (nível inferior), de modo a serconsiderado tendo conectividade (CD > 0). A tabela abaixomostra como um valor é atribuído a CD como uma função donúmero de pais de SYNC potenciais. Este grau é indicado namaioria dos cabeçalhos de MAC e compartilhado com avizinhança. Será usado por outros para decisões desincronização.
De modo a manter seu relógio sincronizado com a rede,um ponto final deve receber sinais de orientação oumensagens freqüentes o bastante de seus pais. Portanto, háuma necessidade de se avaliar a taxa média na qual um pontofinal recebe mensagens de um dado vizinho. Isto terá umpapel importante quando se decide qual vizinho pode atuarcomo um pai de SYNC eficiente. Os vizinhos que são apenasouvidos uma vez em um tempo serão julgados pais de SYNCpotenciais ruins, se comparados com outros que são ouvidosregularmente. 0 indicador de taxa de recepção (pararesumir, RXI) é fácil de implementar e prove uma indicaçãoda taxa na qual as mensagens são ouvidas a partir de umvizinho, embora não seja uma medida exata da taxa derecepção real.
Uma variável de um byte está associada a cada vizinhona tabela de vizinho. Nós chamamos esta variável o RXI dovizinho X e escrevemos RXI(X). Estes RXI são gerenciados deacordo com as regras a seguir:179/345
• 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 os5 RXI
• RXI(X) RXI(X) * RXI_Decay, para todo X e {tabelade vizinho}
Valores altos de RXI indicam que a freqüência derecepção de mensagem é alta. Portanto, vizinhos com valoresde RXI altos têm uma vantagem no processo de seleção de paide SYNC.
Outra discussão aqui reflete como um EP mantém suasincronização a partir do relógio de célula pelo presenteassunto, o que assumiu para esse ponto de discussão que oEP já foi conectado. Na partida ou após uma perda desincronização, um EP é considerado como não sincronizado eentra em uma assim denominada Fase de Descoberta.
Em outras palavras, pelo presente assunto, esteaspecto tem a ver com a provisão de um arranjo dedescoberta de rede, onde um novo nó sem conhecimento préviode seu ambiente é capaz de estabelecer um enlace com umarede existente. Quando da ativação, esse novo nópreferencialmente transmitirá um sinal de orientação dedescoberta por vários canais em sucessão e, então, irá paraum modo de escuta para escutar qualquer resposta. O sinalde orientação de descoberta transmitido inclui umainformação quanto a um canal especifico no qual o novo nóouvirá. Quando nós sincronizados ouvem o sinal deorientação de descoberta, eles transmitem uma mensagem parao novo nó incluindo uma informação necessária para o novonó se sincronizar com a rede. A mensagem transmitida podeincluir tempo, freqüência, identificador de rede, etc. e étransmitida no novo nó indicando freqüência e em temposrandômicos em uma janela de escuta. O novo nó então podecoletar uma informação e escolher a melhor rede dentre oscritérios desejados e sincronizar com o nó de acessoescolhido na rede.
Em uma rede de salto de freqüência, os nós que recémforam acionados e começam a partir do zero não têm idéia deseu ambiente. Eles precisam se conectar e sincronizar comuma rede, o que é complicado pelo fato de não saberem emqual freqüência e em qual tempo a rede opera. A fase dedescoberta do presente assunto de protocolo é uma abordagemalgorítmica para se permitir que o nó rapidamente analiseseu ambiente e procure a melhor rede a que ele pode seconectar, sem perturbar a rede de operação.
Falando amplamente, benefícios adicionais dessepresente assunto incluem que um novo vizinho encontre umaconexão com uma rede em um tempo muito curto, todas asredes da vizinhança são descobertas, e enquanto isso asredes operando na vizinhança não são perturbadas em suasatividades regulares.
Mais especificamente, como o tráfego é muito baixodentro de uma célula e como a célula está continuamentecomutando de um canal para um outro, pode levar um tempolongo para que um ponto final não sincronizado intercepteuma mensagem de um sincronizado. Para aceleração desteprocesso, o ponto final não sincronizado envia sinais deorientação de descoberta sucessivamente em todos os canais.
A ordem dos canais segue a seqüência de salto gerada poruma ID de célula de 0. Há um sinal de orientação dedescoberta por canal no sistema. O canal do primeiro sinalde orientação de descoberta deve ser computadorandomicamente para se garantir que dois pontos finais nãosincronizados não escolham o mesmo na partida. Os sinais deorientação de descoberta são enviados a cadaMAC_Discovery_Beacon_Period ms.
Cada sinal de orientação de descoberta contém nocabeçalho de MAC o número de sinais de orientação dedescoberta remanescentes (campo de NDB) a enviar, e o canalde escuta (campo RxC). Após enviar todos os sinais deorientação de descoberta, o ponto final entra em um modo deescuta durante o MAC_Listening_Window_Length. O canal deescuta é o mesmo que aquele usado para o primeiro sinal deorientação de descoberta. Há uma alta probabilidade de osEPs sincronizados no alcance de rádio do EP receberem pelomenos um destes sinais de orientação de descoberta. Arecepção de um destes sinais de orientação de descoberta. Arecepção de um destes sinais de orientação de descoberta osforça a enviar um "sinal de orientação forçado" no canalrequerido dentro da janela de escuta. Como todo EPsincronizado na vizinhança terá o mesmo padrão, a janela deescuta deverá ser longa o bastante para conter a maioriadas respostas. A fórmula abaixo proporciona o comprimentoda janela de escuta, para o caso em que o número decolisões entre as respostas de vizinho é minimizado.
<formula>formula see original document page 182</formula>
EXEMPLO:
MAC_Max_Nb_of_Neighbors = 10 0 EPsMAC_Nb_of_Sub_TS = 6 Sub_TSMAC_TS_Length = 15 0 ms
->MAC_Listening_Window_Length = 2,5 segundos ou 17 TS
A presente Figura 22 representa um exemplo de fase dedescoberta com um número de seqüência de salto defreqüência básico 0 para uma modalidade operativa em PHY-FHSS-NA-915.
Durante o estado de escuta, uma informação sobre todosos vizinhos que responderam e, principalmente, umainformação de sincronização (endereço, nível, tempo, canal,endereço de célula, GPD e RSSI) é salva na tabela devizinho do ponto final. No fim do estado de escuta, se nãohouver uma resposta, a próxima fase de descoberta serácomeçada após um tempo randômico (veja abaixo). 0 canal doprimeiro sinal de orientação desta nova fase de descobertaé o próximo, na seqüência de salto, após aquele usado najanela de escuta prévia. Este processo é repetido por umperíodo de MAC_Min_Discovery_Phase_Period modulado por umtempo randômico (o valor padrão máximo é de 100 ms) para seevitarem colisões repetitivas entre pontos finais nãosincronizados. Entre o fim da janela de escuta e o começoda nova fase de descoberta, o ponto final pode ficar nomodo de escuta. Este processo pára no fim de um período deescuta, se o ponto final tiver recebido pelo menos umaresposta 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ãosobre partida a quente versus a frio).
Na situação em que um ponto final não é bem sucedidona sincronização com uma célula apósMAC_Max_Nb_o f_D i s c ove ry_Pha s e s fases de descoberta, operíodo de fases de descoberta será aumentado deMAC_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. 0 períodoserá reinicializado para seu valor inicial, se o pontofinal for bem sucedido na sincronização.
No fim da janela de escuta, se pelo menos uma respostavá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 elase adequar às condições de pai de SYNC potencial. Pode serdestacado que pontos finais não sincronizados, pontosfinais não registrados (RS = 0), pontos finais de nível 63,pontos finais não conectados (CD = 0) ou pontos finais deuma célula cheia (CSI = valor máximo) não têm permissãopara enviarem sinais de orientação forçados. Mas, há umachance de um ponto final na fase de descoberta ouvir umamensagem pretendida para um outro ponto final, em cujocaso, deve verificar as condições de pai de SYNC potencial.
A próxima etapa para este ponto final que tenta setornar sincronizado é escolher o melhor acesso à rede. Paraesta seleção, o ponto final considerará todos os vizinhosde que ele recebeu uma resposta ou de que escutoucasualmente um pacote, a menos que eles tenham sidodescartados pelas razões mencionadas acima. Dentre estesvizinhos, ele escolherá o melhor acesso usando um critériocom base nos princípios a seguir:
• CSI Baixo: células com um número menor de pontosfinais serão preferidas em relação àquelas que sejammais ocupadas.
• EP_GPD Baixo: vizinhos com valores de GPD baixos serãopreferidos. O EP_GPD de um vizinho é o atraso depropagação médio global entre o ponto final e o mestrede célula através do vizinho selecionado.
• Bom Nível: um vizinho mais próximo do mestre de célulaserá preferido a um vizinho distante mais saltos domestre de célula.
0 valor de um vizinho, bem como seu CSI, é indicado nocabeçalho de MAC. Os valores de EP_GPD, por outro lado,precisam ser computados. Matematicamente, EP_GPD = GPD dovizinho (conforme reportado em seu cabeçalho de MAC) + LPD+ MAC_GPD_TD.
0 atraso de propagação local (LPD) de um vizinhousualmente é computado a partir do registro deacompanhamento de tentativas passadas de comunicação comaquele vizinho. Este algoritmo é explicado em um capítulodedicado. Durante a fase de descoberta, a computação de umLPD, contudo, é impossível, porque o ponto final ainda nãotrocou mensagens suficientes com o vizinho para acumularuma informação estatisticamente relevante. Neste caso, umaestimativa do LPD com base na leitura de RSSI é usada.
De modo a se fazer uma seleção com base em umacombinação dos princípios mencionados acima, nósintroduzimos um termo para a caracterização da capacidadede um vizinho de atuar como uma fonte de sincronizaçãoadequada:
SYNC_Disc_Merit = EP_GPD * MAC_SYNC_Disc_Weight_GPD +MAC_SYNC_Disc_Weight_Level * LVL + MAC_SYNC_Disc_Weight_CSI* CSISão definidos três parâmetros de camada de MAC,MAC_S YNC_Di sc_We ight_GPD, MAC_SYNC_Disc_Weight_Level eMAC_SYNC_Disc_Weight_CSI. Os valores destes parâmetrosdependerão da importância que se quer dar ao GPD, ao nívelou ao tamanho de célula no processo de seleção. Se alguémregular os dois últimos parâmetros para zero, apenas o GPDserá usado para a seleção do ponto de sincronização.
O processo de seleção para o melhor acesso pode serresumido conforme se segue:
1. Em primeiro lugar, o ponto final computa o EP_GPD paracada vizinho de que ele recebeu uma resposta ou de queescutou casualmente um pacote (desde que o vizinhoseja um pai de SYNC potencial).
2. Para cada vizinho, o ponto final computa o termo parasincronização, SYNC_Disc JYIerit.
3. O ponto final seleciona o vizinho com o valor maisbaixo de SYNC_Disc_Merit e sincroniza seus intervalosde tempo e a seqüência de freqüência com ele. A tabelade vizinho deve ser gerenciada cuidadosamente nesteprocesso, para se permitir que o ponto final recue ese ressincronize com um outro vizinho, se necessário.
4. O ponto final então tem que pedir a este vizinhopermissão para se sincronizar com ele. Para estafinalidade, ele envia uma mensagem específica chamadauma 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 deflag o vizinho como proibido (regular o bitSync_Forbidden para 1 na tabela de vizinho) eprosseguir para a etapa 3 acima com o próximo vizinhoválido na lista com o melhor termo. Várias situaçõespodem levar a esta falha:
a. O vizinho não responde à requisição de SYNC. Acamada de MAC de ponto final repetirá arequisição (por um número de tentativas definidopor Max_Nb_of_SYNC_Request e com um períodomínimo dado por MAC__SYNC_Request_Period maisalguma randomização por uns poucos intervalos detempo), antes de concluir que o vizinho não éalcançável.
b. 0 vizinho responde com um SYNC NACK para indicarque recusa a requisição de sincronização. Nestecaso, o ponto final deve concluir imediatamenteque seu vizinho não é adequado parasincronização.
6. Se o vizinho aceitar (ao enviar um SYNC ACK) , o pontofinal atualizará seu nível e comutará para o modosincronizado. 0 SYNC ACK também contém o número dehardware atual na célula (HFN) e o ITP relativo(RITP). 0 RITP permitirá que o ponto final conheça otempo absoluto, sem esperar por uma mensagem dedifusão de ITP (veja a seção de Tempo).
A tabela da presente Figura 23 proporciona um exemplopara uso do termo com três vizinhos eMA C_S YNC_Di s c_ We i gh t_GPD = 1,
MAC_SYNC_Disc_Weight_Level = 50. Neste exemplo, o vizinhopreferido é o terceiro.
A discussão precedente descreveu o mecanismo para umapartida a frio, isto é, o ponto final não sincronizado nãotinha um conhecimento prévio da rede. Quando um ponto finalo qual já está sincronizado e registrado junto a uma célulaexperimenta uma falha de potência e, então, é ligado denovo, ele pode usar seu conhecimento da rede para recuperarmais rapidamente seu estado a partir de antes da falta depotência. Este processo é denominado uma partida a quente.
Para uma partida a quente, haverá uma noção de célulapreferida no nível de camada de MAC. A célula preferida éuma com que o ponto final foi registrado antes da falta depotência. Em primeiro lugar, o ponto final considerará a simesmo já registrado (bit de RS regulado para 1) e tentaráconectar apenas com sua célula prévia. Se após um número defases de descoberta (definido porWarm_S t ar t_D i s c ove ry_Dura t i on) ele não tiver conseguidofazê-lo, ele considerará as outras células e recomeçará afase de descoberta, sem uma célula preferida, como em umapartida a frio.
Durante a partida a quente, os sinais de orientação dedescoberta contêm o endereço da célula com que o pontofinal deseja se sincronizar. Isto é para impedir os pontosfinais pertencentes a outras células de enviarem sinais deorientação forçados e inundarem o enlace em cada fase dedescoberta por nada. Este campo é regulado para zerodurante uma partida a frio.
É muito importante que o vizinho selecionado chequesua própria conectividade com a rede, antes de reconheceruma requisição de SYNC. Antes de reconhecer uma requisiçãode SYNC, um ponto final deve checar se ele recebeu umamensagem recente de um pai saudável durante os últimosMAC_SYNC_Father_Request_Beacon_Threshold intervalos detempo. Se este não for o caso, ele deverá requisitar umsinal de orientação a partir do pai saudável com o melhorLPD:
MAC_SYNC_Father_Request_Beacon_Threshold <Beacon_Periodicity_SYNC
Mediante o recebimento de uma Requisição de SYNC, umponto final responderá com um SYNC ACK (ou SYNC NACK) ouenviará uma requisição de sinal de orientação para um deseus pais saudáveis, se ele tiver recebido uma mensagemrecente de qualquer um deles. Neste último caso, o pontofinal não responderá à requisição de sincronizaçãoimediatamente, mas esperará pelo vizinho para retransmitirsua requisição. No momento em que o mesmo vizinhorequisitar de novo uma sincronização, o ponto final deveser capaz de aceitar a requisição, porque ele terá recebidomensagens recentes de seus próprios pais saudáveis. Nestecaso, o ponto final enviará um SYNC ACK.
O ponto final que recebeu a requisição desincronização precisa enviar o reconhecimento desincronização ou requisitar um sinal de orientação nointervalo de tempo seguindo-se à recepção da Requisição deSYNC.
O pai que foi requisitado para enviar um sinal deorientação tem que enviá-lo em um dos próximos intervalosde tempo seguindo-se à recepção da requisição de sinal deorientação, antes de MAC_SYNC_Request_Period intervalos detempo terem decorrido. Se este nó já tiver planejado enviaruma outra mensagem (que tem a mesma informação de cabeçalhoque 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çãoenviará um SYNC NACK nos casos a seguir:
• 0 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 (bitde RS = 0).
• O ponto final não tem conectividade. Grau deConectividade = 0 (CD = 0). O grau de conectividadedeve ser atualizado após uma recepção de Requisição deSYNC, principalmente para se recusar uma sincronizaçãono caso em que um ponto final tenta se sincronizar comseu próprio filho (antigo).
Mediante a recepção de um SYNC NACK de um vizinho, seubit Sync_Forbidden deve ser regulado para 1, o que impederequisições adicionais de sincronização de serem enviadaspara este vizinho. Entre fases de descoberta sucessivas, atabela de vizinho não deve ser limpa, de modo a reter estainformação.
O bit proibido associado a um vizinho deve ser limpopara 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 paraum valor positivo).
• O vizinho é novo na tabela de vizinho.
O bit proibido de todos os vizinhos na tabela deve selimpo 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 comreferência à presente Figura 24. EP6 é um medidor novo etem três vizinhos em duas células diferentes. EP4 é omelhor ponto final com que se sincronizar. Neste exemplo,há apenas sete canais diferentes.
Se o único pai de SYNC requisitar uma sincronização apartir de um de seus filhos, o filho terá que recusarimediatamente. O filho também deve perceber que ele perdeusua sincronização. Um medidor, o qual recusou umasincronização, tem que ser marcado (Sync_Forbidden = 1) ,para não ser perguntado mais tarde de novo. Se aspropriedades deste medidor mudarem (nível, célula,ativação), a marca será removida.
0 presente assunto de protocolo vantajosamente provêRequisições de Sinal de Orientação e resolução de bit de RSpara se evitarem rotas circulares. Esse assunto se aplicaprimariamente ao ambiente de uma rede de árvore em que osnó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ívelassociado a seu lugar na célula. Conforme referenciado aquide outra forma, o nó de raiz é de nível 1 e sempre ésincronizado (por definição) . De modo a levar seus dadospara o nó de raiz, um nó deve ser sincronizado na célulacorrespondente.
Dito de uma outra forma, o presente processo desincronização requer uma checagem manual entre um nósincronizado e um outro nó. Um nó o qual se sincroniza emum outro se torna seu filho e o outro nó se torna o pai doprimeiro. O novo nível de nó é um a mais do que aquele deseu pai. Portanto, todos os nós têm um nível acima de 1. Osnó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.
0 problema resolvido de forma bem sucedida pelopresente assunto se refere a guando um nó (nó 1) perde suasincronização e pede a um de seus irmãos ou filhos umasincronização. Se um destes nós (por exemplo, o nó 2)aceitar dar uma sincronização para o nó 1, então, elemudará 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 podeperceber que este não é mais o caso (uma vez que o nível denó 1 agora está sobre seu próprio nível) , e pode tentarencontrar 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á aencontrar um novo pai. Deixado por si, esse processo podese tornar um laço sem fim com nós pedindo uma sincronizaçãopara um outro sem um percurso real para o concentrador (e,assim, sem ser realmente sincronizado). A parte principaldeste problema é o atraso entre o novo estado de um nó e otempo em que seus vizinhos percebem isso.
A solução do presente assunto é com base em umainformação de Sincronização, a qual está presente em todasas mensagens; Sinais de Orientação (os quais são pacotescom apenas a informação de sincronização) ; e com base emrequisições de sinal de orientação (as quais são pacotesrequisitando um sinal de orientação a partir de umvizinho).
Uma das partes principais de informação parasincronização toma a forma de um bit (o bit de RS), o qualindica se um nó ainda tem pais (isto é, o bit de RSregulado para 1) ou não. Este bit está presente em todos ospacotes, porque esta informação deve ser atualizada tãorapidamente quanto possível e assim deve fazer uso dequalquer comunicação. Um nó aceitará dar uma sincronizaçãoapenas se ele tiver recebido uma mensagem relativamenterecente 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 recentede um de seus pais (com o bit de RS regulado para 1) . Seele descobrir esse pai, então aceitará dar a sincronização(SYNC_ACK). Caso contrário, ele enviará uma requisição desinal de orientação para um de seus pais com o bit de RSregulado para um. Este pai enviará um sinal de orientaçãocom toda sua informação de sincronização (incluindo o bitde RS) em resposta. 0 nó pedindo uma sincronização repetirásua demanda e, desta vez, o nó recebendo a requisição deveter recebido o sinal de orientação e deve ser capaz deenviar um reconhecimento de sincronização (SYNC_ACK). Senó não tiver um pai com um bit de RS regulado para 1, elrecusará uma sincronização (SYNC NACK).
A requisição de sinal de orientação permite atualizara informação de vizinhos quando eles considerarem que elanão é recente o bastante, especialmente no caso em que umoutro nó pediu a eles uma sincronização (eles devem estarseguros de ainda terem uma boa conectividade, antes deaceitarem). Essa presente solução vantajosamente provê umaforma relativamente rápida de propagação da informação desincronização entre nós, desse modo se evitando que elescriem uma rede circular virtual sem uma raiz real. Arequisição de sinal de orientação ajuda a atualizar oconhecimento de um nó sobre seus vizinhos, se a informaçãofor considerada antiga demais.
A presente Figura 24 ilustra um exemplo deconfiguração, enquanto a presente Figura 25 representa umprocesso de sincronização, ambas em relação a um exemplo desincronização completa pelo presente assunto de protocolo.Com referência adicional às presentes Figuras 24 e 25, oEP6 é um novo medidor e tem 3 vizinhos em duas célulasdiferentes. EP4 é o melhor EP para sincronização (melhornível, melhor GPD) . Neste exemplo, há apenas 7 canaisdiferentes.
EP6, na ativação, está no nível 0, não sincronizado, eentra em sua fase de descoberta. Ele envia sinais deorientação sucessivos nos 7 canais, e seus 3 vizinhosrecebem, cada um, um sinal de orientação, porque tempo efreqüência combinam em um momento de sorte. Após o envio detodos os sinais de orientação, o EP6 entra em um modo deescuta em uma freqüência que é indicada nos sinais deorientação anteriores. Os 3 vizinhos reagem a este estímuloao enviarem um sinal de orientação "forçado" uns poucosintervalos de tempo (randômicos) mais tarde na freqüênciarequerida. 0 EP6, o qual ouve no canal verde ("greenchannel") recebe estes sinais de orientação e salva ainformação de sincronização. Deve ser notado que duranteesta fase de escuta, o EP3 pode interceptar mensagens dosoutros EPs. Devido à operação do cabeçalho de MAC, o EP3seria 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 dasincronização. Assim sendo, EP6 ajusta seus intervalos detempo em EP4, e requisita uma sincronização. EP4 checa seainda tem uma conexão com o relé de célula 1, seu pai deSYNC, ao requisitar um sinal de orientação, e tão logoreceba o sinal de orientação, envia um SYNC ACK para EP6.EP6 se torna sincronizado e se torna de nível 3 no númerode célula 1.
Note que os EPs números 3, 4 e 5 interromperam suasseqüências de canal durante 1 TS para enviarem um sinal deorientação forçado no canal verde. Isto não é um problema,porque se um outro EP os tiver ouvido neste momento, teriasido lido no cabeçalho o canal que teria que ser usado(endereço de CELL, e número de TS). 0 fato que é um outrocanal que foi escolhido é transparente para a camada deMAC.
A presente Figura 2 6A representa um exemplo de umaConfiguração Inicial, e a presente Figura 26B representa umexemplo de um novo ponto final, ambas ilustrativas decircunstâncias de um ponto final encontrar um melhor pontofinal para fins de comunicação, pelo presente assuntoconforme discutido adicionalmente aqui.
Cada ponto final deve indicar na tabela de vizinho deMAC qual de seus pais enviou o SYNC ACK para a concessão dedireitos de sincronização. 0 indicador tipo de flag SYNCFather (pai de SYNC) serve para esta finalidade.
Pode acontecer de a comunicação de um nó com seu paide SYNC ou as características do pai de SYNC sedeteriorarem até o ponto em que um novo pai de SYNC precisaser encontrado. Dois casos precisam ser considerados.1. A comunicação com o pai de SYNC se deteriora, mas opai de SYNC ainda é um pai saudável, porque está emconformidade com as condições de pai de SYNCpotencial. Neste caso, quando o ponto final roda seuprocesso de seleção de pai de SYNC periódico, ele podeescolher descartar o novo pai de SYNC e pegar um novo,o qual terá um acesso melhor à rede.
2. O pai de SYNC desaparece ou perde seu status de pai deSYNC. Nós chamamos a isso uma perda de pai de SYNC, eocorrerá se:
• O pai de SYNC permanecer silencioso por tempodemais e desaparecer da tabela de vizinho(MAC_Neighbor_Timeout).
• 0 pai de SYNC não está mais em conformidade comas condições de pai de SYNC potencial.
• O pai de SYNC muda seu nível.
• O 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 deseleção pode levar ao mesmo pai de antes, a seleção sendofeita de acordo com critérios de pai de SYNC potencial e otermo em questão.
Se um nó mudar seu nível após a seleção de um novo paide SYNC, então, todos os indicadores tipo de flag deverãoser removidos, exceto pelo último regulado (para o pai querecém enviou o SYNC ACK e permitiu que o ponto finalmudasse seu nível). Um ponto final deve ter apenas um paicom o indicador tipo de flag de pai de SYNC regulado. Nestecaso, o ponto final é considerado sincronizado. Note que umpai que não seja bom para sincronização ainda pode serusado para mensagens de roteamento (se ainda for um pai).
De modo a se comparar o valor relativo de pontosfinais vizinhos como pais de sincronização, considere umtermo 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 quesão pais de SYNC potenciais (veja as condições de pai deSYNC potencial). O componente principal deste termo é oEP_GPD. Termos adicionais são introduzidos para diminuiçãoda probabilidade de escolha de alguns vizinhos que possamser menos adequados como pais de sincronização. 0 termoSYNC_Penalty_LPD é necessário porque o LPD tem uma faixafinita. Quando o LPD de um vizinho é truncado para seuvalor máximo, LPD_Max, o atraso de propagação real não éconhecido e uma constante é adicionada ao termo, para selevar em consideração o risco de selecionar aquele vizinhocom um pai de SYNC. 0 termo SYNC_Penalty_LPD é definidopor:
<formula>formula see original document page 197</formula>
O termo SYNC_Penalty_RXl é necessário para se evitarselecionar como pai de SYNC um ponto final cujo indicadorde 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 porvizinhos que tenham melhor grau de conectividade com afinalidade de se tornar a rede mais estável e confiável,sendo definido por:
<formula>formula see original document page 198</formula>
O caso em que CD = 0 foi mencionado aqui em nome daclareza. Um vizinho com CD = 0 não é, por definição, um paide SYNC potencial e o termo nunca será computado nessecaso.
Periodicamente, um ponto final rodará o processo deseleção de novo pai de SYNC para ver se um pai de SYNCmelhor se tornou disponível. Estes processos de seleçãoperiódicos devem ocorrer em torno de uma vez porhiperquadro. Eles serão implementados de forma tal quepontos finais diferentes em uma célula rodem o processo emtemos diferentes, desse modo se evitando pontos finais emdemasia enviando uma requisição de SYNC ao mesmo tempo. Umnúmero de intervalo de tempo randômico poderia ser usadopara esta finalidade. Por outro lado, quando um ponto finalperde seu pai de SYNC, ele deve começar imediatamente oprocesso de seleção para um novo. O processo de seleçãopara este novo pai de SYNC é descrito abaixo.
A tabela de vizinho será analisada para aclassificação dos vizinhos que combinem com as condições depai de SYNC potencial. Se pontos finais pertencentes aoutras células aparecerem nesta lista, eles deverão serremovidos da lista. Os pontos finais de outras células,quando eles são escutados ao acaso, são lidados de acordocom o processo de decisão de comutação de célula descritoneste documento. 0 termo SYNC_Merit então será computadopara todos os pais de SYNC potenciais na lista. 0 vizinhocom o melhor SYNCJVIerit (valor mais baixo) é denominadoaqui X. 0 vizinho que tinha o melhor SYNC_Merit no momentodo processo de seleção prévio é denominado XP. Se X fordiferente de XP, um contador, SYNC_Top, será inicializadopara zero. Se X for idêntico a XP, o contador SYNC_Top seráincrementado. Se um vizinho decidir ficar no topo da listade pai de SYNC potencial por SYNC_Top_N hiperquadros oumais, ele estará autorizado a se tornar o novo pai de SYNC,desde que esta mudança traga um melhoramento de SYNC Meritmaior do que SYNC_Merit_Hystl. Em qualquer taxa, seescolher X como o novo pai de SYNC trouxer um melhoramentono termo maior do que SYNC_Merit_Hyst2, o ponto finaldeverá selecionar X como o novo pai de SYNC. Uma descriçãodetalhada etapa por etapa deste processo de seleção é dadaabaixo.
Etapa 1: Os vizinhos são classificados de acordo comas condições de pai de SYNC potencial para a feiturade uma lista de pais de SYNC potenciais.Se esta lista estiver vazia, então,
Descartar todas as mensagens de MAC pendentes eir para a fase de descoberta
Caso contrário, se a lista contiver pelo menos umpai de SYNC potencial,
Ir para a etapa 2
Fim do se• Etapa 2: Computar o termo, SYNC_Merit, para cada paide SYNC potencial.
• Etapa 3: 0 pai de SYNC potencial com o menor valor deSYNC_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 (menorSYNC_Merit). 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 temporalde acordo com o algoritmo a seguir:
<formula>formula see original document page 200</formula>• Etapa 6: Procurar um pai de SYNC melhor com oalgoritmo:
Se SYNC_Merit(X) + SYNC_Merit_Hyst2 < SYNC_Merit(SYNCfather), então
Selecionar X como o novo pai de SYNCCaso contrário, manter o pai de SYNC anteriorFim do se
• Etapa 7: Se um novo pai de SYNC tiver sidoselecionado, enviar uma requisição de SYNC para Xe esperar pelo reconhecimento (as requisições deSYNC são detalhadas em uma outra parte destedocumento).
Se a requisição tiver sido reconhecida positivamente,então,
Parar (processo completado)
Caso contrário, se a requisição não é reconhecidapositivamente (reconhecida negativamente ou nãoreconhecida de forma alguma) e o ponto finaltiver um pai de SYNC válido,
Abortar o processo
Caso contrário, se a requisição não é reconhecidapositivamente e o ponto final não tem mais um paide SYNC,
Ir para a etapa 1Fim do se
Durante a etapa 7, se o ponto final decidir sesincronizar 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: enviarSYNC NACK
• Recusar qualquer mensagem: enviar NACK (vejagerenciamento de tráfego)
• Indicar em suas mensagens que não está maissincronizado pela regulagem do bit RS para zero.
Muitos mestres de célula (relês) podem coexistir nocampo. Estes mestres de célula podem fazer parte da mesmarede ou podem pertencer a redes diferentes ou a serviços deutilidade pública diferentes. Uma afiliação de um pontofinal a uma rede é indicada pelo campo de UID no cabeçalhode MAC e pelo valor de SFD no cabeçalho de PHY. Um pontofinal nunca se moverá para uma outra rede, mas poderácomutar para uma outra célula pertencente à mesma rede. Umserviço de utilidade pública pode instalar mestres decélula adicionais em algumas áreas, de modo a se aumentar acapacidade de ritmo de transferência de dados ou para sedesafogar uma célula grande. Mestres de célula adicionaistambém proverão percursos de roteamento alternativos quecontribuirão para a qualidade do serviço. Para se permitirque o tráfego seja disperso uniformemente através dascélulas disponíveis, um ponto final o qual já estáconectado a uma célula deve ter a possibilidade de comutarpara uma outra célula, com ou sem uma intervenção externa.
O método de pedir manualmente a um medidor paracomutar para uma outra célula é muito simples, se um dospontos finais pertencentes ã nova célula estiver em umalcance de rádio. O usuário deve enviar apenas uma mensagempara o ponto final que contará a ele que a célula atualagora é proibida e que a nova é preferida. Então, o pontofinal entrará em uma fase de descoberta para procurar poruma outra célula e, então, se sincronizar com ela.
Um ponto final também deve ser capaz de comutar parauma outra célula automaticamente, se ele considerar queterá uma melhor posição na nova célula e, portanto, ummelhor acesso à WAN. Esta comutação tem que ser feita comalgum cuidado, porque pode perturbar uma ramificaçãointeira da rede. Por esta razão, as condições para mudançapara uma outra célula devem ser estritas, particularmentese tudo funcionar apropriadamente na atual.
Antes de comutar para uma outra célula, um ponto finaldeve conhecer, obviamente, que pelo menos um representantedesta outra célula está na vizinhança. Como a camada físicaestá, por padrão, no modo de escuta, acontece de tempos emtempos de um ponto final receber uma mensagem de uma outracélula. De fato, mesmo se as seqüências de salto não foremas mesmas, elas nunca serão totalmente ortogonais, porqueelas usam o mesmo conjunto de canais e elas nãosincronizadas com a mesma base de tempo. Ocasionalmente, umponto final transmitirá uma mensagem quando os canais deambas as células estiverem alinhados, e se alguns pontosfinais pertencentes à outra célula estiverem no alcance derádio, elas ouvirão a mensagem. Com apenas uma mensagemouvida ao acaso de uma célula adjacente, devido aosparâmetros contidos no cabeçalho de MAC, um ponto finalterá toda a informação para comutar para aquela célulaadjacente.
Se o ponto final julgar que a célula adjacente nãoprove um acesso melhor à rede, ele descartará a informação.Se este acesso for melhor, o ponto final poderá escolher seressincronizar com a célula adjacente.O critério para declaração que um ponto final de umaoutra célula é um melhor acesso à rede é com base em váriosparâmetros:
• Baixo CSI. A menor célula será preferida à maior, demodo a se evitar ter duas células adjacentes com umacheia e outra vazia.
• GPD Baixo. O acesso ao GPD menor será preferido (ovalor usado aqui é o GPD entre o ponto final e omestre de célula através do vizinho, o qual é referidocomo EP_GPD).
• Nível Baixo. Uma célula que provê acesso com menossaltos ao mestre de célula será preferida.
De modo a se fazer uma seleção com base em umacombinação dos princípios mencionados acima, nósintroduzimos um termo para comparação das células umas comas outras.
CELL_Merit = MAC_CELL_Weight_GPD EP_GPD +
MAC_CELL_Weight_Level * LVL + MAC_CELL_Weight_CSI * CSIAqui são definidos três parâmetros de camada de MAC,MAC_CELL_Weight_GPD, MAC_CELL_Weight_Level eMAC_CELL_Weight_CSI. Os valores destes parâmetrosdependerão da importância que se dá ao GPD, ao nível ou aotamanho de célula no processo de decisão de comutação decélula. Se alguém regular os dois últimos parâmetros parazero, apenas o GPD será usado para a comparação dascélulas. Ao escutar ao acaso uma mensagem de uma célulaadjacente, o ponto final computará o termo CELL_Merit paraa nova célula e também para sua célula atual. A condiçãopara 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 duascélulas. Uma vez que o ponto final tenha determinado que anova célula é melhor do que a atual, tem-se que garantirque seja aceito pela nova célula, antes de realmentecomutar. Para esta finalidade, o ponto final pedirá aoponto final de uma outra célula uma sincronização. Arequisição de SYNC e o SYNC (N)ACK serão trocados, conformeé feito em outras situações, exceto pelo fato de o pontofinal precisar ajustar sua freqüência e o tempo detransmissão, considerando que a outra célula opera em umaseqüência de salto diferente.
Uma vez que o novo pai do ponto final deixa a célularesponder com um SYNC ACK, a camada de MAC precisa informara camada acima e fica em sua célula antiga duranteMAC_CELL_Leaving_Process_Duration segundos, antes de deixá-la definitivamente. Nesse ponto, as diferentes camadasprecisam liberar seus buffers e suas ações pendentes. Apósa comutação ser feita, a camada de MAC informa a camadaacima de novo. Este sincronismo é necessário para que acamada NET deixe o registro pelo envio de uma mensagem deNotificação de Saida de Célula de NET.
Um exemplo de um processo completo de comutação decélula é conforme se segue:
o O ponto final ouve ao acaso uma mensagem a partir deum ponto final pertencente a uma outra célula,
o O ponto final salva os parâmetros de vizinho em suatabela de vizinho.O ponto final checa se este vizinho se adéqua àscondições de pai de SYNC potencial. Caso não, oprocesso de comutação de célula é abortado.
O ponto final computa as figuras de mérito decomutação de célula para esta célula atual e para anova célula. Se as figuras de mérito forem favoráveisà nova célula, o ponto final segue adiante com oprocesso de comutação de célula.
O ponto final envia uma Requisição de SYNC para ovizinho, em um canal forçado e em um sub-TS forçado.Se o vizinho concordar e se ele tiver uma boaconectividade com seu pai, ele enviará, então, umreconhecimento de SYNC, mais uma vez em um canalforçado e em um sub-TS forçado. Se o vizinho nãoconcordar, ele enviará um reconhecimento negativo e oprocesso de comutação de célula será abortado. Se ovizinho precisar checar sua conectividade com seu pai,ele requisitará um sinal de orientação e o ponto finaltentando comutar de célula não receberá nenhumreconhecimento imediato.
Se necessário, o ponto final repetirá sua requisiçãode SYNC até receber um reconhecimento ou até o númeromáximo de novas tentativas ser atingido. Neste últimocaso, o processo de comutação de célula é abortado.Uma vez que o SYNC ACK seja recebido, o ponto finaldescarta todas as mensagens (em todas as camadas) desua célula anterior.
A camada de MAC informa a outra camada e começa umtemporizador com uma duração deMAC CELL_Leaving_Process_Duration segundos.o Uma vez que o temporizador expire, o ponto finaldescarta todas as mensagens (em todas as camadas) desua célula anterior,
o O ponto final se sincroniza com o vizinho a partir danova célula. (Tenha cuidado, o número de hiperquadropode ter mudado durante o período de transição).Durante este processo, até o reconhecimento de SYNCser recebido e durante o período de transição o ponto finaldeve lidar com suas atividades de comunicação em sua célulaatual.
• 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 outracélula, ou uma mudança de pai de SYNC com um outroponto final.
• Trabalhar conforme usual, manter as outrasatividades.
Ainda um outro aspecto do presente assunto deprotocolo vantajosamente se refere a um laço de controle deretorno, que pode ser usado para correção de imperfeiçõesde relógios de cristal e para manutenção de umasincronização em uma rede de malha de espectro de dispersãode salto de freqüência (FHSS).
Conforme discutido de outra forma aqui, o presenteprotocolo é baseado em um espectro de dispersão de salto defreqüência (FHSS) para melhor imunidade à interferência epara se estar em conformidade com os regulamentos de rádioem alguns países. Em um sistema de FHSS pelo presenteassunto, todos os nós saltam sua freqüência de canal deacordo com a mesma seqüência pseudo-randômica, de modo aser perfeitamente sincronizado para recepção e transmissão.A performance de um sistema como esse é com base nacapacidade de cada nó ser capaz de manter essa forma desincronização ao longo do tempo. Isto é a razão porque ohardware de nó requer uma referência de tempo de cristalcom boa estabilidade. Devido ao fato de essas referênciasde tempo serem dispendiosas, é útil implementar ummecanismo de compensação acionado por software paramelhoria da estabilidade no tempo dos nós.
Na presente rede de exemplo, conforme discutido deoutra forma aqui, uma estrutura tipo de malha é provida,onde o relê de célula é a raiz da malha e o metrônomo darede. Como uma regra, essa informação de sincronismo épropagada para longe da raiz até os nós de célula. Nopresente assunto de protocolo, a cada vez em que um nó secomunica com um outro nó mais próximo da raiz, elerealinhará seu relógio para estar em sincronização com arede. Além disso, essas correções de relógio consecutivasvantajosamente têm a média calculada no tempo, sãofiltradas e processadas para se proporcionar uma informaçãosobre quão rápido o relógio de nó está correndo comrespeito ao relógio médio dos nós mais próximos da raiz.Esse presente recurso permite uma correção de software doritmo de relógio de nó que o colocará em sintonia com arede por um longo periodo de tempo. Portanto, falandogeralmente, o presente assunto provê os benefícios depermitir o uso de cristais de custo relativamente baixo nosnós de rede, mas com uma estabilidade no tempo aumentada darede.
Mais especificamente, a presente Figura 27 ilustra umadistribuição típica de ressincronizações e correções dederiva de cristal no tempo, pelo presente assunto.
Conforme referenciado de outra forma aqui, uma boasincronização é a base do presente protocolo, motivo porqueuma limitação inerente àquele aspecto de outra foram viriaprincipalmente da acurácia do cristal. De modo a se limitaro tráfego e para evitação de colisões internas, tão poucossinais de orientação de sincronização quanto possível sãoenviados. Contudo, como resultado, em condições de tráfegobaixo, o número de oportunidades para ressincronização dorelógio com um pai, portanto, será relativamente pequeno.Como uma conseqüência, cada ponto final geralmente terá umdeslocamento de relógio com o nível superior. Para númerosde nível relativamente maior, esse deslocamento se tornariasignificativo em relação ao relógio de relê de célula. Istopoderia levar a uma perda de sincronização, se fossedeixado o deslocamento crescer acima de algum limite. Maisainda, como um ponto final pode ressincronizar seu relógiocom vários pontos finais pais, um mecanismo de cálculo demédia poderia ser utilizado vantajosamente.
Uma abordagem do presente assunto como uma solução éantecipar a deriva do oscilador de cristal local comrespeito aos relógios de pai. Se essa deriva for assumidacomo sendo constante (que mostrou ser uma boa hipótese, sea temperatura não mudar muito rapidamente) , um procedimentode compensação eficiente poderá ser implementado. Portanto,ao invés de esperar pela próxima ressincronização, o pontofinal pode ajustar seu comprimento de intervalo de tempopara diminuição do próximo valor de ressincronização derelógio. O algoritmo de compensação usa uma filtração depassa baixa para lidar com múltiplos percursos desincronização e para evitação de instabilidades. Adescrição detalhada desse algoritmo é discutida em outrolugar aqui.
Sempre que o receptor ressincronizar seu relógiolocal, dois valores são gravados: o valor da correção, oqual é Clock_Correction (k), e o tempo destaressincronização, o qual é Resync_Time(k). Este tempo édado pelo valor do relógio de tempo real do sistema nomomento da ressincronização. O parâmetro k é usado aquipara numeração das sucessivas ocorrências deressincronização. Para estes dois valores e com oconhecimento do tempo de ressincronização prévio,teoricamente é possível avaliar a deriva relativa dooscilador de cristal local, Xdrift. Para ser útil para finsde compensação de deriva de cristal, estas avaliações devemser acuradas.
Cada valor de correção de relógio pode ser consideradocomo sendo o resultado de duas contribuições. A primeira éuma deriva lenta devido a uma diferença entre a freqüênciade cristal local e a freqüência de cristal média nos pontosfinais pais. A segunda contribuição é um deslocamento detempo randômico ocorrendo no momento em que um tempo decurso de pacote é estimado. Isto é resumido na equação aseguir:
<formula>formula see original document page 210</formula>
onde ôt(k) é um erro randômico devido à incerteza no tempode propagação do pacote a partir da camada de MAC detransmissor para a camada de MAC de receptor, quando umnú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 preferencialmentesomadas, 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 desteserros randômicos se tornará crescentemente menor conformesucessivas correções de relógio forem somadas, conforme sesegue:
<formula>formula see original document page 211</formula>
Por esta razão, os valores de correção de relógiosucessivos são somados até eles cobrirem um tempo maior doque o valor mínimo especificado pelo parâmetro de camada deMAC MAC_Xdrift_Tmin. Uma vez que este valor de tempo sejaexcedido, a deriva de cristal pode ser avaliada com oseguinte:
<formula>formula see original document page 211</formula>
A faixa de soma deve respeitar a condição:
<formula>formula see original document page 211</formula>
onde MAC_Xdrift_Tmin é escolhido grande o bastantepara ter:
<formula>formula see original document page 211</formula>Xdrift_accuracy é a acurácia almejada do algoritmo (emtorno de 1 ppm). MAC_Xdrift_Tmin também deve ser muitomaior do que o intervalo entre dois intervalos de tempo depulo (conforme discutido em outro lugar aqui), de modo queo processo de integração no tempo ocorra para suavização depequenos defeitos de compensação de deriva de cristal.
A presente Figura 28 representa em formato esquemáticoum algoritmo de compensação de deriva de relógio local paraa prática pelo presente assunto de protocolo, enquanto apresente Figura 29 representa (também em formatoesquemático) um filtro de passa baixa para correção dederiva de cristal, tudo de acordo com o presente assunto.
A estimativa referenciada aqui com referência a umaderiva de referência não será usada diretamente paracompensação da deriva de oscilador de cristal. De modo acalcular a média por várias fontes de sincronização e ficarlivre de flutuações, um filtro de passa baixa (veja apresente representação da Figura 29) será implementado.
Este filtro de passa baixa é definido por:
Xdrift _jllt{n) = A χ Xdrift {ti) + 5 χ Xdrifl _ filt{n -1),
onde Xdrift_filt(n) é a estimativa de deriva de cristalfiltrada e A, B são os coeficientes de filtro que serãoajustados para a obtenção de um cálculo de média adequado epara tornar o laço de controle de retorno resultanteestável o suficiente. Estes dois coeficientes de filtroterão valores dados pelos parâmetros de camada de MAC aseguir:
A s MA C _ Xdrift _ Filter _ AB = MAC _ Xdrift _ Filter _ BO comprimento instantâneo do intervalo de tempo de sistemaTsiot (n) é definido, e esse valor pode ser expresso como asoma do comprimento de intervalo de tempo padrão e umpequeno termo de correção:TslJn) = TS__Length + ATs!o,(n)
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-sedesprezar 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 deintervalo 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:
àTs!o!(n) = ATshl (η-1 ) + TS _ Length χ Xdrift _ filt(n)
De modo a se garantir que a descrição matemática doalgoritmo representado pela presente Figura 28 seja bementendida, o processo inteiro é resumido aqui com umpseudocódigo.
Primeira inicialização
Xdrift_filt = 0
Start_Time = primeiro valor de tempo de ressincronização
Sum_Clock_Corr = 0
Mediante uma recepção de um sinal de orientação ou dequalquer mensagem válida, fazer
Acumular a correção de relógio
Sum Clock Corr = Sum Clock Corr + Clock CorrectionAtualizar o tempo desde a última estimativa de derivade 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 mensagemCaso 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_filtAtualizar a correção de intervalo de tempoATslot = ATslot + Xdrift_filt * TS_LengthInicializar Start_Time para a próxima iteração
Start_Time = último valor de Resync_Time
Inicializar o acumulador de correção dereló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 dederiva de cristal é de em torno de 1 ppm. Istoprovavelmente tornará impossível uma correção direta doparâmetro MAC__TS_Length, especialmente se a resolução doSACT não for muito alta. Portanto, é sugerido, no começo decada intervalo de tempo, recarregar o temporizador decontagem regressiva com o valor de comprimento de intervalode tempo padrão, MAC_TS_Length. A cada MAC_Xdrift_LeapTSintervalos 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úmerocomeçando a partir de O e incrementado em cada intervalo detempo, não é o número de intervalo de tempo usado para aidentificação da posição em um hiperquadro. Deve serdestacado que para uma compensação ótima de deriva decristal, o recarregamento de SACT acima deve ser realizadocom a acurácia plena provida pelo firmware, conformeespecificado pelo parâmetro MAC_FW_Acccuracy. A resoluçãodo algoritmo de correção depende da faixa de intervalo detempo de pulo, conforme mostrado pela equação a seguir:
<formula>formula see original document page 215</formula>
Uma resolução melhor ou igual a 1 ppm deve seralmejada. Por outro lado, a faixa de intervalo de tempo depulso deve ser pequena o bastante para se evitaremcorreções de relógio maiores do que a margem de intervalode tempo. Ao satisfazer a esse critério, a desigualdade aseguir 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 umsistema de autogerenciamento e otimização de pontos finaisque é organizado em células. Cada célula tem um relê decélula o qual serve à finalidade de retransmitir toda ainformação para e da rede para uma outra rede de área amplaoperando em um protocolo de TCP/IP. Devido a esse fato, aassimilação de um ponto final a uma dada célula não écontrolada e pode crescer sem limites. Obviamente, os relêsde célula têm limitações de recurso e um crescimento alémde 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ãocomunicados para todos os pontos finais na célula. Ospontos finais que estão se unindo à rede e poderiam ter apossibilidade de se unirem a mais de uma célula usarão estainformaçã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 pertode ficar cheia, a célula B será escolhida pelo presenteassunto em questão para sincronização, mesmo se asindicações forem que a célula A pode ser uma célula muitomelhor para a transferência (via upload) de tráfego derede.
Embora as células operem em isolamento devido àsseqüências de salto de freqüência quase ortogonais, emraras ocasiões o tráfego pode ser escutado ao acaso de umacélula para a outra para pontos finais localizados nasfronteiras se tocando. Nesses eventos, os indicadores detamanho de célula podem ser usados para o comando de umadecisão para migração de uma célula cheia para uma célulavazia ou muito menos cheia. Assim sendo, pelo presenteassunto discutido de outra forma aqui, com base nessespresentes processos, os tamanhos de célula serãogerenciados e equilibrados ao longo do tempo, permitindoque um autogerenciamento e uma otimização continuem.
Mais particularmente, os presentes aspectos desteassunto são aplicáveis para modalidades configuradas comouma rede de árvore, onde os nós são organizados em célulascom um concentrador (ou um nó de raiz) na "cabeça" de cadacélula. Conforme discutido de outra forma aqui, cada nó temum nível associado a seu lugar na célula. O nó de raiz é denível 1 e sempre deve ser sincronizado (por definição) . Demodo a levar seus dados para o nó de raiz, um nó deve sersincronizado na célula correspondente. O processo desincronização requer uma checagem manual entre um nósincronizado e um outro nó. Um nó o qual se sincroniza comum outro se torna seu filho e o outro nó se torna o pai doprimeiro. O novo nível de nó é um a mais do que aquele deseu pai. Portanto, todos os nós têm um nível acima de 1. Osnós do mesmo nível são denominados filhos. O grupo de pais,irmãos e filhos de um nó é denominado seus vizinhos.
Pelo presente assunto, cada nó mantém uma tabela deseus vizinhos. A informação sobre os vizinhos é usada paravárias finalidades (sincronização, roteamento e similares),incluindo a transmissão de pacotes de difusão.Efetivamente, a difusão na realidade é uma mensagem demultidifusão enviada para todos os filhos do nó. Assim, éimportante que cada nó esteja na tabela de vizinho de pelomenos um de seus pais, para se garantir a entrega depacotes de difusão. Isto é um dos papéis da requisição desincronização: pelo envio de um reconhecimento desincronização (SYNC_ACK), um pai garante que seu novo filhoesteja em sua tabela de vizinho. Pelo presente protocolo, opai de um nó o qual envio um SYNC_ACK é denominado umSYNC_FATHER deste nó. 0 SYNC_FATHER é o único pai quegarante que o nó esteja em sua tabela de vizinho e, assim,o único pai o qual garante que enviará uma difusão para onó. Um nó sempre deve ter um SYNC_FATHER.
Sempre que a memória de um nó estiver limitada, damesma forma estará sua tabela de vizinho. 0 problematécnico surge quando a tabela está cheia e um novo nórequisita uma sincronização. 0 nó sincronizado com a tabelacheia não poderá reconhecer positivamente a requisição desincronização do novo nó sem a inserção dele na tabela.
Qualquer atividade como essa poderia levar a um nó nacélula não recebendo difusões (se ele não estiver na tabelade um outro pai). Infelizmente, se o direito desincronização for recusado, então, poderia levar a um nóórfão (não em uma célula) não ser capaz de entregar seusdados. Da mesma forma, o nó "pai" não pode criar espaçopara o novo nó pela remoção de qualquer um dos direitosnesta tabela (porque fazê-lo poderia fazer com que um nónão recebesse difusões).
A solução obtida pelo presente protocolo degerenciamento é primariamente com base em duas coisas. Emprimeiro lugar, um bit (EPSF significando pai de syncpotencial suficiente) é enviado em cada pacote e mantido natabela de vizinho para cada vizinho. Este bit é reguladopara 1 por cada nó, se o número de pai e filhos em suatabela de vizinho estiver acima de um dado limite (o qual éescolhido para indicar que eles poderiam enviar comsegurança uma requisição para um outro nó). A segunda parteé a mensagem de notificação de fora de tabela (TON) . Combase no bit de EPSF, um nó recebendo uma nova requisição desincronização enquanto sua tabela de vizinho está cheia,pode decidir remover um de seus filhos, se seu bit de EPSFfor um. Mas isto deve indicar para seu filho que ele nãomais estará em sua tabela de vizinho. Isso é realizado peloenvio da mensagem de TON para seu filho. Mediante orecebimento desta mensagem, este filho olhará se seu paiera seu SYNC_FATHER. Se este fora o caso, então, ele deveencontrar um outro SYNC_FATHER para garantir que esteja natabela de vizinho de um de seus pais e, assim, recebadifusões.
Esta solução provê uma forma de nunca recusar umasincronização com um novo nó, enquanto se garante que todosos 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 einformação de vizinhança pelo presente assunto deprotocolo, a camada de MAC está encarregada dogerenciamento vis-à-vis de vizinhos. Assim sendo, a cadavez em que um ponto final recebe uma mensagem, ele tambémsalva ou atualiza o parâmetro do remetente em uma lista.
Portanto, pelo presente assunto, apenas parâmetros devizinho a 1 salto são conhecidos e salvos no ponto final. 0relê de célula é o único dispositivo que conhece o statusdos 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ópriatabela de vizinho, mas também indicará para as camadassuperiores (particularmente para a camada de NET, por meioda 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 dosvizinhos. Ela é limitada no tamanho pela variávelMax_Nb_of_Neighbors. Para cada vizinho, os parâmetros são:
• Address, (Endereço) 4 bytes (o endereço de MAC dovizinho).
• Levei, (Nível) 1 byte (o último nível conhecidodo vizinho. 0 nível é 0 se o vizinho não forsincronizado. O nível 1 é o relê de célula).
• Average RSSI, (RSSI Médio) 1 byte (RSSI é medidodurante a recepção e indicado pela camada física. Ovalor salvo é um valor médio de RSSI por uma janeladeslizante 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 tempoquando a última recepção ocorreu. Com a informação deseqüência de canal, proporciona o último canal).
• Last Reception Time, (Tempo de Última Recepção) 4bytes (o tempo quando a última recepção ocorreu. Areferência deste tempo é livre para a implementação.Contudo, é sugerido que seja o tempo de ativação donó.).
• Delta SACT, ASACT, 2 bytes (A diferença de SACTentre o EP e seu vizinho. Este valor é renovado a cadavez em que um a mensagem é recebida a partir de seuvizinho. Isto indica o desalinhamento entre os 2 EPs) .
• GPD, 2 bytes (o atraso de propagação médio globalentre 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 localentre o EP e o vizinho).
· Last reception rate update (Última atualização detaxa de recepção) (o último tempo em que a taxa derecepção deste EP foi atualizada).
• Received rate indicator, RXI, 1 byte (Indicadorde taxa recebida) (ele prove uma indicação dafreqüência com que o painel dianteiro recebe mensagensdeste conteúdo. Ele impedirá o ponto final de sesincronizar com um vizinho que dificilmente sejaouvido).
• Sync_Forbidden, 1 bit (um indicador tipo de flagindicando que este ponto final recusou umasincronização).
• Sync_Father, 1 bit (um indicador tipo de flagindicando que este vizinho permitiu que o ponto finalficasse sincronizado. Apenas um vizinho pode ter estebit regulado. Ele é regulado quando o SYNC ACK érecebido. Quando um ponto final muda seu nível, eledeve limpar todos os indicadores tipo de flag, excetoaqueles atribuídos ao vizinho com que ele recém sesincronizou. Um ponto final deve ter um pai com o bitSYNC Father regulado, de modo a considerar a si mesmosincronizado).
• Sync_Son, 1 bit (um indicador tipo de flagindicando que o EP permitiu que seu vizinho fossesincronizado com ele. Este indicador tipo de flag deveser removido se o nível de seu vizinho mudar).• Registered, 1 bit (Registrado) (um indicador tipode flag indicando que este vizinho está registrado emuma célula).
• Enough_Potential_Sync_Fathers, 1 bit (umindicador tipo de flag indicando se este vizinho temum número de irmãos e pais com que ele possa sesincronizar (Sync_Forbidden bit = 0) , isto é, é maiordo que MAC_Good_Number_of_Potential_Sync_Fathers).
• Father Acknowledged load, (SAck) 1 byte (cargareconhecida de pai) (número médio de reconhecimentosrecebidos por este pai, excluindo-se osreconhecimentos pretendidos para o EP em si. Isto émantido apenas se o EP for um pai. Isto é usado paraestimativa da carga deste pai, a qual, por sua vez,será usada para a determinação da janela derandomização para uma transmissão).
• CSI, 2 bits (o indicador de tamanho de céluladeste vizinho).
Devido a limitações de memória, a tabela de vizinhotem um tamanho finito e não pode conter mais deMax_Nb_of_Neighbors entradas. Portanto, é necessário selivrar de algumas entradas conforme elas se tornareminúteis para a operação da rede.
A tabela de vizinho é gerenciada de acordo com osprincípios gerais a seguir:
• Apenas vizinhos que satisfaçam às condições de pai deSYNC potencial serão adicionados à tabela.
• Desde que a tabela não esteja cheia, qualquer novovizinho que satisfaça às condições de pai de SYNCpotencial será adicionado à tabela.• Se a tabela estiver cheia quando um novo pai de SYNCpotencial chegar, o novo vizinho tomará o lugar de ummenos importante, se um vizinho como esse existir. Aimportância de um nó na tabela de vizinho é com baseno termo de sincronização. Se não houver possibilidadede liberação de algum espaço na tabela, a informaçãosobre aquele novo vizinho será descartada.
• Nós a partir dos quais nada foi recebido por um longoperíodo de tempo serão considerados como tendo deixadoa vizinhança a 1 salto. Se nenhuma mensagem tiver sidorecebida a partir de um vizinho por um período detempo mais longo do que MAC_Neighbor_Timeout, ovizinho 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 umafalta de potência, todas as entradas da tabela devizinho deverão ser apagadas.
O processo de liberação de espaço na tabela pode serdetalhado adicionalmente conforme se segue. Deve serdestacado que este processo não é realizado em uma base emandamento, mas apenas quando um novo pai de SYNC potencialprecisar ser inserido em uma tabela a qual já esteja cheia.
• Checar as condições de pai de SYNC potencial. Sealgumas entradas não combinarem mais com as condiçõesde pai de SYNC potencial, elas poderão ser apagadas databela.
• Os vizinhos mais importantes na tabela são aqueles como termo de sincronização mais baixo. Se um nó precisarser retirado, aquele com o termo mais alto deverá serremovido (veja a exceção para o pai de SYNC abaixo).Se um ponto final não for sincronizado, qualquervizinho que combine com os critérios de pai de SYNCpotencial poderá ser adicionado a sua tabela de vizinho. Aimportância relativa destas entradas será definida deacordo com o termo para a fase de descoberta,SYNC_Disc_Merit.
Se este ponto final estiver em um processo de partidaa frio, apenas os vizinhos pertencentes à célula preferidaserão permitidos na tabela de vizinho. Se este ponto finalestiver em um processo de partida a quente, todos os paisde SYNC potenciais, qualquer que seja a célula a qualpertençam, serão permitidos na tabela.
Se um ponto final for sincronizado, a importância dasentradas será com base no termo de sincronização(SYNC_Merit). Se um nó precisar ser retirado, aquele com oSYNC_Merit mais alto deverá ser removido. Há uma exceção aesta regra: o pai de SYNC não pode ser removido da tabela.Se um pai precisar ser removido quando o pai de SYNC calharde ter o pior SYNC_Merit, o menos pior a seguir deverá serremovido.
O termo de sincronização depende, dentre outrosparâmetros, do indicador de taxa de recepção, RXI. Como osrecém-chegados têm um RXI baixo, isto criará uma histeresepara 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ãointroduzidos na tabela. Eles são avaliados dinamicamentepara se checar se eles poderiam oferecer um melhor ponto desincronização.
A presente Figura 3OA também descreve em formato defluxograma o presente gerenciamento de tabela de vizinho.
Os pontos finais têm endereços de MAC fixos e podempotencialmente se sincronizar e conectar a qualquer célula.Contudo, o protocolo deve levar em consideração que algumascélulas são proibidas. Este pode ser o caso se o usuário /serviço de utilidade pública quiser controlar a partilha depontos finais em células diferentes, ou meramente se umusuário não quiser compartilhar sua rede com um outrousuário / serviço de utilidade pública (este último caso émanipulado normalmente por se terem diferentes IDs deserviço de utilidade pública no cabeçalho de PHY). De modoa se gerenciar a afiliação de uma célula, um endereço decé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élulaestá autorizada ou não. Esta informação então é mantida nonível de camada de MAC, o que não considerará uma célulaproibida para sincronização.
Todas as células proibidas são reautorizadas pelacamada de MAC, se o ponto final ficar não sincronizado porum período de tempo mais longo do queMAC_Unsynchronized_Timeout.
Em uma partida a frio, uma vez que o nó sejasincronizado, ele informa à camada de API estasincronização bem sucedida, indicando o endereço de célulacorrespondente. A camada de API deve informar, então, àcamada de MAC quando o ponto final se tornar registrado. Acamada de MAC não autorizará outros nós a se sincronizaremcom ela, se não estiver registrada. Assim que um nó éregistrado, a camada de MAC salvará o endereço de célula eo usará como uma célula preferida, no caso de uma partida aquente.
Em uma partida a quente, o nó procura sua célulapreferida. Se ele for bem sucedido em encontrar a célula ese sincronizar com um de seus membros, a camada de MACconsiderará a si mesma já registrada (bit de RS = 1), eimediatamente autorizará as requisições de sincronização deseus vizinhos. A camada de API precisa contar à camada deMAC se esta hipótese estava correta ou não.
A partida a quente acelerará o processo desincronização de uma célula, após uma falta de potência degrande escala.
Em geral, pelo presente assunto de protocolo, doistipos de mensagens são reconhecidos: dados de monodifusãocontendo LPDU a partir da camada de LLC e requisições deSYNC. Os dados de monodifusão são reconhecidos (ou não) commensagens de ACK (ou NACK) e requisições de SYNC pormensagens de SYNC ACK (ou SYNC NACK).
ACK, NACK, SYNC ACK e SYNC NACK devem ser enviados naintervalo 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 dequadro de MAC (FID), inserido no cabeçalho de MAC. Amensagem de (não) reconhecimento mencionará este ID dequadro em seu próprio cabeçalho de MAC. 0 ID de quadro deMAC é um contador, incrementado pela camada de MAC em cadaenvio de dados de monodifusão ou de requisição de SYNC.
Para cada LPDU, o LLC pedido a enviar, a camada de MACindicará de volta se a mensagem de dados de monodifusão foireconhecida (ACK), não reconhecida (NACK) ou nãoreconhecida (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çalhode MAC, ou ID de quadro de MAC. Quando a mensagem de dadosde difusão tiver sido enviada, a camada de MAC a notificarápara a camada de LLC.
Ainda com referência a reconhecimentos, maisespecificamente, os presentes aspectos deste assunto emrelação a reconhecimentos de difusão provêem umafuncionalidade usada para a distribuição da mesmainformação a partir do nó mestre para todo nó pertencente auma rede de malha. Um aspecto de uma difusão padrão é quenunca há uma garantia que todo receptor pegou a informaçãoe, mais particularmente em uma rede de malha, a mensagempode precisar ser encaminhada para todo nó, qualquer queseja seu nível. Para se garantir que todo nó receba osdados, o presente assunto de protocolo inclui uma abordagemalgorítmica a qual usa uma difusão reconhecida, cujaabordagem também pode ser vista como uma sucessão detransmissões de multidifusão.
Conceitualmente, será entendido que o presenteprocesso de sincronização resulta em se proporcionar umnível a todo nó na rede. 0 nível representa o número desaltos 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 donó; nível igual, denominados irmãos; e nível mais alto(além do ponto de extração), denominados filhos. Umadifusão pode ser gerada apenas pelo nó mestre da rede. Adifusão deve ser encaminhada pelos nós de receptor paraseus próprios filhos.
Uma detecção de duplicação evita que um nó encaminhe amesma difusão mais de uma vez. A identificação destaduplicação é com base em um ID de difusão gerado pelo nómestre. A propagação de difusão é reconhecida entre cadasalto. Para se poupar tempo quando muitos filhos estãopresentes abaixo de um nó, um reconhecimento da difusão éorganizado. O nó remetente seleciona seus filhos e adicionaseu endereço de MAC no cabeçalho da mensagem de difusão. Osnós de receptor checam se seu endereço está presente nocabeçalho para aceitarem a difusão. A ordem dos endereçosdo cabeçalho proporciona ao destinatário uma ordem dereconhecimento. O ponto final o qual tem o primeiroendereço tem que reconhecer no primeiro intervalo que sesegue à recepção; o segundo, no segundo intervalo, e assimpor diante. Os nós que foram reconhecidos (ou não) sãoarmazenados. A mensagem de difusão é repetida apenas paraaqueles que não reconheceram.
Dito de uma outra forma, por aspectos adicionais dopresente assunto, quando uma mensagem tem que ser enviadapara vários pontos finais (Difusão / Multidifusão, indicadopor LLC), a camada de MAC envia duas mensagenssucessivamente (em dois intervalos de tempo). A primeiramensagem, uma lista de Difusão / Multidifusão, contémendereços na próxima mensagem de difusão. A segunda é amensagem de difusão e contém os dados de difusão, com um IDde difusão no parâmetro. A ordem dos endereços na Mensagemde Lista de Difusão proporciona ao destinatário uma ordemde reconhecimento. 0 ponto final, o qual tem o primeiroendereço, tem que reconhecer no primeiro subintervalo detempo do intervalo de tempo que se segue à recepção; osegundo em segundos subintervalos de tempo, e assim pordiante. Os pontos finais que reconheceram (ou não) sãoindicados para a camada de LLC, a qual pode repetir (ounão) a mensagem para aqueles os quais não reconheceram. Seum ponto final recebeu uma mensagem de difusão e deveencaminhá-la, preferencialmente ele será configurado paraesperar por tempo suficiente, para deixar os outros pontosfinais reconhecerem, de modo a evitar uma interferência.
Essa abordagem prove múltiplos benefícios, tal como umainundação de transmissão ser controlada; os nós apenassalvam a informação sobre seus filhos, o que resulta em umganho líquido de memória; uma redundância garante que quase100% dos nós obtenham os dados; e a velocidade depropagação de dados pela rede é nivelada.
0 presente assunto de protocolo vantajosamente usa umaCRC de 32 bits (Verificação de Redundância Cíclica) paraevitar uma corrupção de mensagem por ruído ouinterferência. A CRC é computada pelo remetente nocabeçalho de MAC inteiro e LPDU e colocada no fim doquadro. No lado de receptor, o valor da CRC é usado para severificar a validade da mensagem. Se a CRC combinar com amensagem, o quadro será aceito. Se não combinar, ela édescartada.
A CRC usada é a CRC padrão de 32 bits do IEEE 802.3. Apresente Figura 3 0 provê uma representação esquemática deuma implementação típica de CRC de 32 bits. O polinômiogerador dessa CRC é:
A CRC é computada com um registrador de deslocamentode retorno linear inicializado para OxFFFFFFFF (ou qualquerimplementação equivalente). A computação começa com oprimeiro byte do cabeçalho de MAC e termina com o últimobyte de LPDU. Cada byte é alimentado no registrador dedeslocamento com o bit menos significativo primeiro. Ao fimda divisão polinomial, o registrador de deslocamento contémo resto da divisão. 0 primeiro byte a ser deslocado parafora deste registrador corresponde ao primeiro byte deredundância. Ele é interpretado pelo bit menossignificativo primeiro e deve ser complementado até umantes de ser apensado a LPDU.
Com referência à segurança, o presente assunto deprotocolo preferencialmente não prove um serviço deencriptação. Como tal, os datagramas são enviadospreferencialmente na interface de ar sem encriptação.Contudo, isto não quer dizer que o presente assunto deprotocolo não é um protocolo seguro. De fato, é umprotocolo projetado, a camada física para o que usa umatécnica de FHSS com um padrão de salto de freqüência muitolongo. Uma escuta clandestina nesse sistema requereria umesforço de engenharia significativo. Esta segurançaintrínseca é adicionalmente melhorada pelo uso deseqüências de Fibonacci para se tornar o padrão de saltodiferente em cada célula.
Caso essa abordagem para a segurança seja consideradainsuficiente para algumas aplicações críticas, está noescopo do presente assunto suplementar essa segurança pelaencriptação dos dados de usuário nas camadas de aplicativo.
Certos aspectos vantajosos do presente assunto sereferem ao que pode ser considerado geralmente comoregulagem 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çõessegundo as quais a carga de tráfego cresce acima de umponto de paralisia total em uma rede de malha Aloha comintervalo. Em certos aspectos, os presentes procedimentosusam a monitoração de reconhecimentos recebidos paraavaliação da densidade de tráfego. Pelo menos váriosbenefícios identificáveis dessas presentes metodologias sãoque ela permite que o tráfego de enlace ascendente em umarede de malha flua em condições ótimas e evita umaparalisia total de tráfego devido a uma operação da redealé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 usaro canal além de sua densidade de tráfego ótima. Isto énecessário porque o presente assunto de protocolo operacomo um sistema Aloha com intervalo, e para um sistema comoesse, uma densidade de tráfego acima de um dado limite podeaumentar a taxa de colisão para um nível inaceitável ebloquear completamente o fluxo de dados (isto é, o fluxo dedados se torna paralisado). 0 presente controle de tráfegopreferencialmente é usado apenas para uma transferência(via upload) de tráfego, a partir dos pontos finais para orelê de célula (ou mestre de célula).
Mais particularmente, o presente assunto de controlede carga de tráfego é aplicável geralmente a qualquer redede malha com um nó atuando como um ponto de extração dedados. O tráfego de dados a partir dos nós individuais atéeste ponto de extração é considerado como um tráfego deenlace ascendente. Conforme esse tráfego de enlaceascendente gerado na rede cresce mais alto, colisõesinternas entre pacotes ocorrerão. Em algum ponto, essascolisões serão freqüentes o bastante para degradarem oritmo de transferência efetivo do sistema. A relação entreprobabilidade de colisão e ritmo de transferência efetivo ébem conhecida com a teoria de Aloha com intervalo. A teoriaclássica lida com o caso em que nenhum agente deemperramento externo está presente. Aqui, a situação é maisdifícil de se analisar, porque há ambos os tipos de colisãoao mesmo tempo, isto é, colisões internas devido ao tráfegointerno e colisões externas com os outros usuários dabanda.
Assim sendo, o presente assunto vantajosamenteintroduz um mecanismo de controle para desaceleração dotráfego de dados conforme ele crescer acima de um dadolimite. Os nós precisam ser capazes de temporariamentemanterem 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 usaremo canal além de sua densidade de tráfego ótima. Se isto nãofor feito, a densidade de tráfego poderá aumentar a taxa decolisão para um nível inaceitável, que não apenasdiminuiria a performance, mas que poderia bloquearcompletamente o fluxo de dados.
Portanto, pelo presente assunto, de modo a controlarapropriadamente a carga de tráfego, um ponto final precisaavaliar a quantidade de tráfego indo através da rede. Paraas presentes finalidades de descrição, um primeiro nó noalcance de rede de um segundo nó e na direção do ponto deextração para o segundo nó será denominado um nó pai emrelação a esse segundo nó. A presente Figura 31 é umarepresentação esquemática do presente assunto demonitoração de carga de tráfego, onde um dado nó B estáouvindo mensagens de (N)ACK a partir de seus pais Ae C.
Para as finalidades de controle de carga de tráfegomencionadas acima, um ponto final de exemplo (nó B naFigura 31 de exemplo) gravará os reconhecimentostransmitidos por seus pais AeCe não pretendidos para simesmo. Esses reconhecimentos proporcionarão informaçãosuficiente para se avaliar a carga de tráfego, porque, nopresente protocolo, um nó tem que reconhecer todos ospacotes de dados que ele recebe. Esta abordagem éconsistente com o fato que o gerenciamento de tráfego seráusado principalmente pelos pontos finais se comunicandodiretamente co um relê de célula, a partir do que apenasreconhecimentos são transmitidos em uma situação detransferência (via upload). Contudo, essa informação, nãoobstante, não é suficiente, porque um nó precisa ser capazde distinguir entre uma situação de tráfego baixo que gerapoucos reconhecimentos e uma situação de tráfego muito altoque também gera poucos reconhecimentos, porque a maiorparte dos pacotes é perdida devido a colisões. Para estafinalidade, preferencialmente cada nó gravará todas astentativas de comunicação com os nós pais e computará umataxa de sucesso de comunicação média. Combinando-se a taxade reconhecimentos ouvidos ao acaso e a taxa de sucesso decombinação, um nó será capaz de estimar a densidade detráfego de uma forma não ambígua.
De uma forma formal, pode-se definir a densidade deentrada de tráfego Ra como o número médio de pacotes dedados chegando ao nó A (Figura 31) em um intervalo detempo. Este conceito é útil para se medir quão ocupado estáo nó A. Também é conhecido a partir da teoria de Aloha comintervalo que a densidade de entrada de tráfego tem umvalor ótimo. Se a densidade de entrada de tráfego cresceracima daquele valor ótimo, o ritmo de transferência caidevido a colisões. Todos os pacotes de dados chegando ao nóA são considerados na definição de densidade de entrada detráfego, independentemente de eles serem ou não recebidosde forma bem sucedida. Contudo, por razões práticas, ospacotes emanando do nó B preferencialmente são excluídos(uma vez que o foco atualmente está em se tentar derivaruma regra de comportamento para esse nó B) . Também édefinido o número médio de reconhecimentos emanando apartir do nó A e ouvidos ao acaso pelo nó B (excluindo-seaqueles 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 onó B estar em um estado de escuta. A partir da teoria deprobabilidade elementar, pode ser mostrado que a estimativapara a densidade de entrada de tráfego no nó A é dada peloseguinte:
<formula>formula see original document page 234</formula>Para se evitar estourar para cima um nó com pacotesalém da densidade de entrada de tráfego ótima, a taxa detransmissão de pacotes é limitada pelo presente assunto.
Para isto, é definida a densidade de entrada de tráfegomáxima Rmax- A partir da teoria de Aloha com intervalo, istodeve ser igual a um, mas para ser conservador no projeto, épreferível usar um valor menor. A densidade de entrada detráfego total no nó A é a soma da densidade tráfegoestimada Ra e do tráfego que o nó B gerará para o nó A. Onó B modulará o tráfego que ele gera para o nó A, de modo ase 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 aimplementação desta limitação é enviar as mensagens em umtempo randômico em uma janela de randomização decomprimento Tw- O comprimento da janela de randomizaçãodeve 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 suajanela de randomização de acordo com o pai com a densidadede entrada de tráfego mais alta, mesmo se o pacote não forpretendido para este pai.
As tarefas a seguir preferencialmente são realizadasem todo nó na rede. Elas são para a monitoração de todos osreconhecimentos ouvidos a acaso a partir dos nós pais; paraa gravação de todos os sucessos / as falhas de comunicaçãocom todo nó pai; para manutenção de um registro do tempogasto no estado de transmissão ou de escuta; para acomputação da taxa de sucesso CSR e para a computação dadensidade de entrada de tráfego estimada, R; e paradesaceleração da repulsão de transmissões se a densidade deentrada de tráfego para o pai mais ocupado se tornar grandedemais.
Todas essas variáveis médias (densidade de tráfego deentrada, taxa de reconhecimentos escutados ao acaso, taxade sucesso de comunicação e probabilidade de um nó estarescutando) podem ser computadas com um algoritmo de médiadeslizante para evitação do uso de memória em excesso demicroprocessador.
Com referência a esse assunto em termos um poucodiferentes, pelo presente assunto, uma densidade de entradade tráfego máxima definida pode ser referida comoMAC_Traffic_Density_max, de modo que a densidade de entradade tráfego total no ponto final A, agora incluindo otráfego de B para A seja dada por:
<formula>formula see original document page 236</formula>
onde Tx_Window é o comprimento em intervalos de tempo dajanela de randomização usada para a transmissão de umpacote. O pacote de dados será transmitido em um intervalode tempo escolhida randomicamente nesta janela derandomização. Segue-se uma equação para a computação docomprimento desta janela como uma função de transmissõesparâmetros prontamente medidos:
<formula>formula see original document page 236</formula>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 derecepção e SacJcA é o número médio de reconhecimentostransmitidos por A e recebidos por B por intervalo detempo. Para as finalidades práticas, o comprimento deTx_Window precisa ser delimitado. O resultado deste cálculoserá truncado de modo a sempre estar na faixa a seguir:MAC_Tx_ Windosv_ min < Tx_ Window < MAC_ Tx_ Window_max .
O comprimento de janela de randomização então serácomputado com o seguinte:
<formula>formula see original document page 237</formula>
onde é usado 0 MAC __Traj]lc _ Dem ,Iy _ max Q ponto finaltem que monitorar o tráfego para cada um de seus pais, demodo a se ter um valor atualizado de SackA· Ao final de cadaintervalo de tempo, o ponto final computa novos valores dosparâmetros Sacka em sua tabela de vizinhos. Isto tem que serfeito sistematicamente, independentemente de um pacotedaquele vizinho ter ou não sido recebido. Nós usamos paraisto uma janela de média deslizante conforme definidoabaixo:
O se nenhum (N)ACK for recebido a partir de AJ_ se um (N)ACK for recebido a partir de A
<formula>formula see original document page 237</formula>
Nessa fórmula, η se refere ao número de intervalo de tempoe Ntmw é o número de intervalos de tempo na janela demonitoração de tráfego. Este número é dado pelo parâmetrode camada de MAC Ntmw O MAC JTraffic,^Momtoring Window . Qbtambém é atualizado em cada intervalo de tempo com oseguinte:
<formula>formula see original document page 238</formula>
Obviamente, se um ponto final tiver vários pais, elesempre deve dimensionar o comprimento de sua janela derandomização de acordo com o pai com a densidade de entradade tráfego mais alta, mesmo se o pacote não for pretendidopara este pai.
Devido ao custo de hardware, o tamanho de memória parase pouparem mensagens não será ilimitado do ponto de vistade um sistema. Os pacotes durante seu curso entre um pontofinal e um mestre de célula são armazenados como em bufferem nós. Para se evitar ficar diante de situações de tráfegobloqueado sem solução, quando a memória está cheia, oarmazenamento de pacotes deve seguir algumas recomendaçõesimportantes.
O armazenamento de pacotes deve ser dividido em duascategorias:
• Pacotes indo em enlace ascendente: enlace ascendente,enlace rompido, notificação de falta...
Pacotes indo em enlace descendente: enlacedescendente, difusão...
0 número de pacotes pertencentes a cada categoria deveser monitorado ao longo do tempo e é chamado
nb_of_uplink_buffered_packets e
nb of downlink_buffered_packets. Há um número máximo depacotes que podem ser salvos para cada categoria.
nb_of_uplink_buffered_packets <MAC_Max_nb_o f_up1ink_buf f ered_packe t snb_of_downlink_buffered_packets <MAC_Max_nb_o f_down1ink_buf f e red_packe t snb_of_uplink_buffered_packets +nb_of_downlink_buffered_packets < memory size
Para se manter esta informação, é necessário quecamadas diferentes indiquem a categoria do pacote que elasenviam / recebem. Como o mestre de célula apenas recebe umtráfego de enlace ascendente e envia um tráfego de enlacedescendente, estas categorias podem ser respectivamentecomparadas com pacotes armazenados em buffer chegando esaindo.
Uma vez que um buffer de qualquer tipo esteja cheio,se uma mensagem do tipo correspondente for recebida, acamada de MAC deverá responder ao remetente com umamensagem NACK e descartar o pacote, já que não há lugarpara salvá-lo.
Para o caso do mestre de célula, se a conectividade deWAN for boa, o buffer de enlace ascendente (entrando) nuncadeve estar cheio. De fato, o ritmo de transferência da WANé altamente superior àquele da Linknet. Se o buffer deenlace ascendente calhar de estar cheio, o mesmo algoritmoserá usado e o mestre de célula começará a enviar NACK paraos pacotes chegando. Esta situação em contrapartidadegradará altamente as performances da rede e poderá criarinstabilidade de rede e perdas de pacote.
Com respeito a pontos de discussão a seguir sobre apresente programação de mensagens, deve ser entendido que,neste contexto, uma mensagem se refere a qualquer outropacote além de um reconhecimento. Quando a camada deaplicativo a requisita, ou quando há uma mensagem recebidaa encaminhar, uma camada de NET determina o(s) endereço(s)5 de destino. A camada de LLC lida com a fragmentação e aretransmissão de mensagens. Estas duas camadas enviamrequisições para a camada de MAC que adiciona o cabeçalhode MAC aos pacotes e os envia para a camada física paratransmissão.
Dentre estas camadas, a MAC está encarregada deprogramar em qual intervalo de tempo a mensagem seráenviada. O objetivo principal desta programação érandomizar no tempo as transmissões, de modo a se evitaremcolisões com pacotes de vizinhos.
A camada de MAC não apenas deve programar as mensagensde dados vindo das camadas superiores, mas também seuspróprios pacotes (reconhecimentos, requisições e sinais deorientação).
As mensagens podem aceitar algum atraso na suatransmissão, enquanto reconhecimentos devem ser enviados nointervalo de tempo da recepção. Estas restrições e anecessidade de randomização no tempo são a base para oprocesso de programação de pacotes.
Com referência às presentes prioridades paramensagens, a presente Figura 32 é uma tabela que mostra umalista de prioridade de mensagem de exemplo de acordo com opresente assunto de protocolo. Em geral, há dois tiposprincipais de pacotes que a camada de MAC deve programar:aqueles vindo das camadas superiores (LPDU) e aquelesgerados pela camada de MAC. A primeira categoria pode serdividida em dois tipos, dados e notificação de falta deenergia, enquanto a segunda categoria inclui requisições esincronização (SYNC RQST) e reconhecimentos (SYNC ACK ouSYNC NACK), reconhecimento de outras mensagens (ACK ouNACK), sinais de orientação, requisições de sinal deorientação e sinais de orientação de descoberta. Asmensagens de dados podem ter um cabeçalho de MAC diferente,dependendo de sua natureza (monodifusão, difusão, ITP dedifusão...), mas todas elas serão tratadas da mesma formade um ponto de vista de programação.
Algumas mensagens devem ser enviadas com prioridade;dentre todas estas mensagens, os reconhecimentos são osmais importantes. Um (N)ACK deve ser enviado na intervalode tempo em que ocorreu a recepção da mensagem demonodifusão correspondente; da mesma forma, o SYNC (N)ACKdeve ser enviado no mesmo intervalo de tempo que a SYNCRQST correspondente.
O MAC normalmente não deve enviar mais de uma mensagemem um dado intervalo de tempo, exceto vários sinais deorientação forçados, se o hardware puder lidar com isso. Nocaso raro em que um EP precisasse reconhecer mais de umamensagem ou requisições de sincronização no mesmo intervalode tempo, então, uma deveria ser enviada e a outracancelada. A razão para isto é que o EP que transmitiu amensagem ou requisição inicial espera um reconhecimentoneste intervalo de tempo e considera a transmissão umafalha após isso (assim, é inútil transmitir um (N)ACK ouSYNC (N)ACK após o intervalo de tempo atual). Embora outrospacotes além de reconhecimentos sejam inicialmenterandomizados em uma janela, eles não estão absolutamenterestritos a isso e podem ser postergados.
As requisições estão em seguida na lista deprioridade, com a SYNC RQST imediatamente antes deRQST_Beacon.
Todos estes pacotes são necessários para a redefuncionar apropriadamente e, assim, são de prioridade maisalta do que os dados a transportar. Os dados estão emseguida nesta lista de prioridade, seguidos pelos sinais deorientação (em um canal forçado ou não). Estes sinais deorientação são na realidade cabeçalhos de MAC usados parase dar uma informação de sincronização. Uma vez que a mesmainformação está em todos os cabeçalhos de MAC, se qualquermensagem for transmitida na janela em que um sinal deorientação não forçado é requisitado, este sinal deorientação não precisa ser transmitido. Concernente aossinais de orientação forçados, os quais são disparados pelarecepção de um sinal de orientação, eles precisam serenviados na janela de escuta correspondente, mas apenas sehouver um intervalo de tempo disponível: incluindo um novonó para a rede não deve perturbar os nós já sincronizados.
Há duas exceções que suplantam a ordem de prioridadedefinida acima: a primeira é quando um EP experimenta umafalta de potência, e a camada de API o notifica para acamada de NET. Esta requisição muda o modo de recepçãonormal para um modo de economia de potência passivointerrompido pela transmissão de notificações de faltacurta. Se um outro EP receber uma destas notificações, elea retransmitirá com uma ordem de prioridade de dadosnormais. 0 segundo caso é durante a fase de descoberta,onde sua ordem é sem significado, uma vez que o MAC apenastransmite sinais de orientação de descoberta ou escutasinais de orientação "forçados".
A programação de uma mensagem consiste em decidir emqual intervalo de tempo ela será transmitida. Há váriasrestrições que se aplicam a esta tarefa. Em primeiro lugar,devem ser seguidas as regras de prioridade descritas naseção prévia; esta prioridade é aplicada quando duasmensagens devem ser enviadas no mesmo intervalo de tempo.Regras adicionais são necessárias para a definição destatarefa de programação.
Conforme dito anteriormente, os reconhecimentos são daprioridade mais alta e também devem ser enviados no mesmointervalo de tempo que a mensagem ou requisição desincronização que os disparou. Os reconhecimentos não podemser empurrados no tempo como o podem as mensagens (todamensagem pode ser postergada, exceto os sinais deorientação forçados, os quais também têm uma janeladefinida, mas são de prioridade mais baixa e podem sercancelados, para se dar lugar a qualquer outro pacote, senecessário).
Como resultado desta primeira regra, se uma mensagemfora programada no mesmo intervalo de tempo que a recepçãode dados de monodifusão, então, esta mensagem seráempurrada por 1 intervalo de tempo, para se permitir que acamada de MAC reconheça o pacote recebido. Apenasreconhecimentos podem ser enviados em um intervalo de tempoquando um pacote de LPDU foi recebido.
De modo a não sobrecarregar a rede, qualquer LPDU eSYNC RQST devem ser randomizados no tempo. A randomizaçãode SYNC RQST é feita na camada de MAC e é discutida em umaoutra seção.
A cada vez em que um pacote é recebido a partir dacamada de LLC, a camada de MAC o adiciona em um FIFOdedicado a mensagens de dados. Se nenhum pacote de dadosestiver sendo enviado, a camada de MAC checará se há umamensagem neste FIFO. Se este for o caso, então, a janela detransmissão será atualizada (veja a seção de controle decarga de tráfego) e um temporizador de contagem regressivaé determinado randomicamente. Este temporizador édecrementado a cada começo de intervalo de tempo e, quandoatinge zero, a mensagem é enviada durante o intervalo detempo.
Há várias exceções a esta regra. Se uma mensagem deprioridade mais alta já estiver programada ou umreconhecimento for esperado, então, a mensagem será deixadano FIFO e o temporizador de contagem regressiva reguladopara expirar pelo próximo intervalo de tempo. Ao contrário,se um sinal de orientação forçado foi programado no mesmointervalo de tempo, a mensagem de dados é programada (e/ouno próximo para um pacote de monodifusão) , então, o sinalde orientação forçado é cancelado.
O sinal de orientação forçado deve ser enviado najanela de escuta do ponto final em uma fase de descoberta.Deve ser randomizado nesta janela. Se o intervalo de tempojá tiver sido tomado, então, o próximo intervalo de tempodeverá ser testado quanto à disponibilidade, fazendo umciclo até o começo da janela de escuta, se o fim foratingido. Este procedimento deve continuar até um espaçoser encontrado para a transmissão do sinal de orientaçãoforçado ou o ponto final perceber que todos os intervalosde tempo já estão ocupador, em cujo caso ele deve cancelaro sinal de orientação forçado.
Quando um pacote já programado é empurrado no tempopara deixar espaço para um reconhecimento, então, todos ospacotes programados mais tarde serão empurrados pela mesmaquantidade de intervalo de tempo. Isto deve concernirapenas a SYNC RQST e Beacon RQST, uma vez que pacotes dedados ficam no FIFO até o intervalo de tempo em que elessão enviados (em cujo ponto já foi determinado que nenhumreconhecimento era esperado).
Finalmente, há várias regras concernentes àtransmissão dentro de um dado intervalo de tempo. Asmensagens de dados sempre são enviadas no começo doprimeiro subintervalo de tempo; isto maximiza o espaçodisponível para dados e permite que os pontos finais enviemseus reconhecimentos no último subintervalo de tempo.
Os reconhecimentos de sincronização também devem serenviados no mesmo intervalo de tempo que a requisição; aSYNC RQST deve ser enviada no segundo subintervalo de tempoe o reconhecimento correspondente no último subintervalo detempo, independentemente de a resposta ser negativa oupositiva. Se a SYNC RQST disparar um RQST Beacon parachecar a conexão com um pai, então, ela também deverá serenviada no último subintervalo de tempo (onde o SYNC (N)ACKseria enviado se o pai fosse bom).
Os sinais de orientação devem ser randomizados entre osegundo e o quinto subintervalo de tempo para nãointerferirem com o começo de mensagens de dados oureconhecimentos. A mesma regra deve se aplicar ao pacote defalta de MAC.Em outras presentes versões do protocolo, osreconhecimentos são feitos no intervalo de tempo seguindo-se à mensagem ou à requisição, o que significa que ospacotes de dados poderiam não ser enviados em intervalos detempo sucessivos. A presente versão não tem esta restrição,mas é compatível com o fato de não enviar dados traseiracom traseira, se o hardware não puder lidar com isso. Osreconhecimentos foram colocados no mesmo intervalo de tempopara estarem na mesma freqüência que os pacotes originais enão ganhar tempo. Resumido para a presente versão:
• (N)ACK deve ser enviado no mesmo intervalo de tempo emque a recepção de uma mensagem de monodifusão ocorreu.
• SYNC (N)ACK deve ser enviado no mesmo intervalo detempo 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 o5° subintervalo de tempo.
• Se o pacote for empurrado por um intervalo de tempo,então, todos os pacotes já programados serãoempurrados.
A presente discussão se refere, mais particularmente,a vários aspectos de sistema de notificação de falta dopresente assunto. Especificamente, é notado que os pontosfinais que experimentam uma falta de potência possuem umainformação importante, que poderia ser retransmitida para osistema de coleta de dados, podem ser aplicados parafinalidades muito úteis de gerenciamento de rede. Contudo,durante uma falta de potência, o suprimento de energia foicortado. Para dispositivos de baixo custo, os quais nãocontêm dispositivos de armazenamento de energia, istosignifica que eles têm energia limitada disponível e nãoserão capazes de continuarem a participar na rede. 0problema então surge quanto a como mover esta informaçãovaliosa para o relê de célula sob estas circunstâncias.
A presente solução é baseada vantajosamente no usopara a retransmissão da informação dos pontos finais quenão experimentem uma falta de potência. Em cada queda depotência, haverá uma franja de autodefinição de onde ospontos finais na zona de queda de potência serão capazes dese comunicarem com pontos finais que ainda estejam tendopotência.
Os pontos finais que experimentam a falta de potênciaentrarão em um modo de queda de potência uma vez que umafalha de potência seja detectada. Isso imediatamentecessará a operação normal da rede e iniciará umas poucasmensagens de queda de potência curtas por uma janela detempo randomizada para se evitarem colisões. Como ainda écapaz de manter um tempo de forma acurada devido a umacompensação de deriva de oscilador, será capaz deselecionar canais de freqüência corretos e tempo paragarantir que os pontos finais com potência no alcance sejamcapazes de capturarem estas mensagens. Uma vez que ospontos finais com potência capturem a mensagem de falta depotência, eles serão capazes de armazenarem esta informaçãoe enviá-la usando o protocolo de rede normal.
Se a conectividade de rede tiver sido influenciadapela fala de potência, os pontos finais usarão as funçõesde autogerenciamento de rede normais para orestabelecimento da conectividade, se possível. Umainformação de queda de potência é armazenada durante estetempo e não é perdida. Se a zona de falta de potência forgrande apenas uma percentagem das mensagens de queda depotência será reportada, mas deve ser suficiente para seinferirem problemas de falta verdadeiros com uma correlaçãocom uma informação de rede de eletricidade, pelo menos apartir da perspectiva de finalidades de gerenciamento derede.
Mais particularmente, pelo presente assunto, quandouma falta de potência ocorre, a camada de MAC entra em ummodo espacial (requisitado por API). A camada de MAC párade ouvir e envia 3 mensagens muito curtas com a energiaremanescente do EP. Cada uma dessas mensagens é randomizada(mas ainda alinhada com os intervalos de tempo) em umajanela de 5 s. Estas mensagens de falta são processadas portodo mundo que puder ouvi-las. Estas mensagens também sãonumeradas com um número de falta (1 incremento por falta,não por mensagens enviadas). Se antes de a primeiramensagem de falta ser enviada o EP recuperar sua potência,ele então cancelará as notificações de falta (mas a camadade API é livre para enviar uma mensagem de recuperação depotência). Mas, se a potência voltar após a primeiramensagem de falta ser enviada, então, o EP enviará as duasremanescentes.
Quando um vizinho que ainda tem potência ouve umamensagem de falta, sua camada de MAC indica para a camadade NET (através de LLC) a notificação de falta, o endereçode vizinho, o número de falta e o tempo quando a mensagemde falta chegou. Será tarefa da camada de NET encaminharesta informação para o relê de célula da mesma forma quefoi usada para mensagens de enlace ascendente regulares (ouclássicas).
0 presente assunto de protocolo assegura de formabenéfica uma análise de outros aspectos da performancerelacionada à rede. Especificamente, uma ferramenta deavaliação ambiental de RF embutida é provida para acalibração das necessidades de performance de transceptoresde RF. Em particular, uma ferramenta de análise de ambientede rádio estatística é embutida nos nós de uma rede de umaem questão para fins de provisão de recomendações para omelhoramento do hardware.
O presente sistema é pretendido para uso em bandas deISM. Estas bandas usualmente caracterizam um nível muitoalto de interferência não controlada. As especificações dohardware de RF, bem como a performance esperada da rededependem fortemente do ambiente eletromagnético nestasbandas. Dois aspectos deste ambiente precisam serconsiderados. O primeiro é a perda de percurso ou condiçõesde ponta de perfuração distai. Embora uma grande quantidadede informação esteja disponível sobre este tópico parabandas de ISM, nenhum dado estatístico confiável estádisponível para a situação específica de medidor deeletricidade para medidor de eletricidade relevante paraesta rede. 0 segundo aspecto do problema é o nível deinterferência. 0 conhecimento deste parâmetro é muitoimportante, porque a maior parte do custo de um transceptorde RF está associada a interferências e como combatê-las deforma eficiente. O presente assunto provê a implementaçãode uma ferramenta de análise de ambiente embutida noprotocolo. Isto é uma ferramenta potencialmente valiosapara diagnóstico de rede e planejamento. Também será oponto de partida para uma definição de hardware de próximageração para qualquer sistema, porque provera um meio parasuporte de qualquer redução de custo do hardware de RF,pela provisão de um backup de análise de ambiente extensivopara garantir que qualquer novo hardware resultante tenhaas especificações requeridas para funcionar neste ambiente.
Para essas finalidades, os nós da rede sondarão o ambienteeletromagnético com a função de RSSI (indicador deintensidade de sinal recebido) do receptor. Devido ànatureza continuamente mutável deste ambiente, é necessárioque um grande número de medições de RSSI seja válido de umponto de vista estatístico. Portanto, para se evitarconfundir a largura de banda limitada com todas essasmedições, um processamento de dados estatístico seráplicado no nó. Desta forma, apenas uma informaçãosignificativa terá que ser reportada para o aplicativo.
Dois tipos diferentes de análise de ambiente sãoespecificados neste protocolo. O primeiro é usado paraexploraçã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 perguntascomo: qual é o comprimento de pacote ótimo para se evitaremcolisões com os outros usuários da banda? A segunda análiseajudará a responder a perguntas como: qual é a rejeição decanal adjacente necessária para se evitarem colisões? Qualé a probabilidade de uma colisão ocorrer se dois nósestiverem a alguma distância um do outro?
Um benefício principal é que ela permite a otimizaçãodo hardware de RF que precisa funcionar em condiçõesespecíficas, para a prática do presente assunto em umambiente de campo em particular.
Considerando-se essas presentes ferramentas de análiseambiental em maiores detalhes, será entendido que asespecificações do hardware de RF, bem como a performanceesperada da rede, dependem fortemente do ambienteeletromagnético. Dois aspectos deste ambiente precisam serconsiderados. O primeiro aspecto é a perda de percurso oucondições de propagação. O segundo aspecto do problema é onível de interferência. A camada de MAC pode sondar oambiente eletromagnético com a função de RSSI do receptor,e obter um número relativamente grande de medições de RSSIpara validez estatística. Dois tipos diferentes de análiseambiental são especificados neste protocolo. 0 primeiro éusado para exploração das características de tempo dainterferência e usa a função de autocorrelação de RSSI. Osegundo se concentra na intensidade da interferência e usaa função densidade de probabilidade de RSSI.
Com respeito à funcionalidade de análise ambiental emquestão, o objetivo do Modo de Aquisição de Autocorrelaçãode RSSI é medir o RSSI médio e sua função de autocorrelaçãoem um canal único. Neste modo, o ponto final interromperápor algum tempo sua seqüência de salto normal e suastarefas 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 dadapelo parâmetro de camada de MAC RSSI_Sampling_Rate. Estasleituras então serão processadas para a extração do valormédio e da função de autocorrelação. A camada de LLC enviaa requisição para a camada de MAC com dois argumentos deentrada: o número de canal em que realizar a análise e umnúmero máximo de amostras usadas para a terminação daanálise de ambiente.
O RSSI médio, RSSI_avg, será computado de formaiterativa, conforme explicado pelo algoritmo a seguir:
<formula>formula see original document page 252</formula>
Ifn - maximum number of readings, then stop açquisition process end
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 doRSSI. A função de autocorrelação será avaliada apenas paraum conjunto restrito de valores de atraso. Este conjunto devalores é:
<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 deautocorrelação são atualizados. O processo de atualizaçãopara os valores de função de autocorrelação de RSSI,AF_RSSI(m,η), é:
Initialization
<formula>formula see original document page 253</formula>
After each RSSI_avg update doFor each m e RSSI _ A F _ Delays do
AF _ RSSJ (m,η) = o novo valor da função de autocorrelação de RSSI para um atraso mAF _ RSSl (m, η -1) = o valor antigo da função de autocorrelação de RSSI para um atraso m
<formula>formula see original document page 253</formula>
Quando o número requisitado de leituras de RSSI éatingido, o processo de aquisição e de atualização pára. Ovalor RSSI_avg e os valores de AF_RSSI (m) para cada atrasom então são reportados para a camada de LLC na mensagem deconfirmação. Este relatório então será encaminhado para acamada NET e para a API, o que a enviará para o relê decélula. A estrutura dos argumentos de saída para aconfirmação é mostrada abaixo:
RSSI avg AF RSSl(0) AF RSSI(I) AF_RSSI(90) AF_RSS1 (1 00) j
RSSI_avg é um campo de 1 byte e os AF_RSSI(m) são campos de2 bytes. Após esta análise de ambiente, a camada de MACressincroniza seus intervalos de tempo e retoma suasatividades prévias de comunicação.
Pelo presente assunto, deve ser notado também que esteprocesso de análise de ambiente deve ser curto o bastantepara se evitar que o ponto final perca sua sincronizaçãocom a rede de malha. Mais ainda, o modo de aquisição deautocorrelação deve ser usado preferencialmente em nós nãopróximos demais do relê de célula de modo a se evitar umaperturbação no fluxo de dados através da rede.
Com respeito à funcionalidade de análise ambiental emquestão, o objetivo do modo de aquisição de PDF de RSSI épara medir a função densidade de probabilidade (PDF) dasleituras de RSSI em três canais selecionados. Neste modo, oponto final fica saltando seu número de canal de acordo coma seqüência de salto de célula, como no modo normal. 0 nócontinua com todas as suas tarefas de comunicação usuais eusa seu tempo livre para sondar o ambiente.
Três canais diferentes são projetados para a aquisiçãode PDF de RSSI e eles fazem parte da seqüência de saltobásica. A camada de LLC envia a requisição para a camada deMAC com quatro argumentos de entrada: os três números decanal para análise e um valor de contador máximo(RSSI_PDF_Max_Count) usado para a terminação da análiseambiente. O 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 emquestão.
Sempre que o receptor saltar para um dos canaisselecionados para medição de RSSI, ele requisitará umaleitura da camada PHY. Apenas uma leitura de RSSI érequisitada por intervalo de tempo. Este valor de RSSIentão será usado para a atualização da PDF de RSSI paraaquele canal. A PDF é um arranjo de 24 intervalos (bins),cada um destes intervalos (bins) correspondendo a uma faixade RSSI de 3 dB, conforme mostrado na presente Figura 33.
Um contador está associado a cada intervalo (bin). Porexemplo, se a leitura de RSSI for igual a -113 dBm, ocontador associado ao intervalo (bin) 2 será incrementado.
De uma forma geral:
<formula>formula see original document page 255</formula>
onde bin_k_counter é o contador associado ao intervalo(bin) k.
Há algumas exceções a esta regra. Se o valor de RSSIestiver 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 RSSIestiver 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 dequadro for detectado em um intervalo de tempo, antes daleitura de RSSI, este intervalo de tempo não deverá serusado para a atualização de PDF de RSSI. Se um começo de umdelimitador de quadro for detectado em um intervalo detempo, após a leitura de RSSI, este intervalo de tempopoderá ser usado para uma atualização de PDF de RSSI. Afinalidade disto é evitar que um tráfego de Linknetinterfira com a aquisição de PDF. A meta desta medição épegar uma imagem de fontes de interferências externas noscanais usados pela rede. Cada um dos contadores deintervalo (bin) começa a partir do zero, quando o processoé inicializado e tem uma faixa máxima de 4096. Quandoqualquer um destes contadores atinge o valor máximoRSSI_PDF_Max_Count (< 4095), a aquisição de PDF de RSSIpara aquele canal é parada. Quando a aquisição de PDF deRSSI está completada para os três canais selecionados, acamada de MAC poderá reportar os resultados para a camadade LLC. A estrutura da saída é mostrada na presente Figura 34.
Se o nó perder sincronização, comutar para uma outracélula ou experimentar uma falta de potência (isto poderiaser feito na ativação), todas as mensagens armazenadas embuffer devem ser apagadas.
A camada de MAC usa vários tipos de mensagens paragerenciamento de suas numerosas tarefas. Nem toda mensagemcontém o mesmo nível de informação. De modo a se pouparlargura de banda de RF e para não enviar bytes inúteis, ocabeçalho de MAC será diferente para quase cada tipo demensagem. Contudo, toda mensagem deve prover uma informaçãode sincronização para qualquer um que queira ouvi-la. Destaforma, nenhuma mensagem será inútil, mesmo se uma mensagemfor ouvida por um ponto final que não seja o destino.
No nível de camada de MAC, o endereço de um pontofinal é o número de série do medidor em si. Assim, umendereço é fixo e único, e é de 4 bytes de comprimento.
0 quadro de mensagem no nivel de MAC é comporto por:
• Um cabeçalho de MAC: ele representa todos osparâmetros necessários no nivel de MAC. Nós podemosdividi-lo em subseções: uma parte comum para todos ostipos de mensagem e uma parte dinâmica.
• Um corpo de quadro, o qual é a unidade de dados deprotocolo de LLC, denominado LPDU.
• Uma seção de seqüência de verificação de quadro, aqual é dos bytes necessários para a computação dadetecção de erro no cabeçalho de MAC e no corpo dequadro.
A presente Figura 3 5 abaixo mostra todos os campos quepodem estar presentes no nível de MAC. 0 campo e asestruturas de mensagem diferentes são descritas de outraforma aqui.
De acordo com o presente assunto, há uma parte docabeçalho a qual é comum a todos os tipos de mensagens:
LV, Layer Version (versão de camada): indica a versãoda camada de MAC.
FT, Frame Type (tipo de quadro) : estes bits indicam otipo do quadro. Veja as seções relativas da presente Figura36 para a informação relacionada ao tipo de quadro de MAC.
Note que os tipos de mensagem são dispostos em ordem deprioridade.
SA, Sender Address (endereço de remetente): o endereçode remetente / fonte tem 4 bytes de comprimento.
0 cabeçalho de MAC tem uma seção dinâmica, na qual oscampos abaixo não aparecem em toda mensagem. Eles sãodescritos aqui de forma geral, com maiores detalhesdeclarados de outra forma aqui para cada tipo de mensagem.RS, Estado de Registro:
Indica se o ponto final está registrado para umacélula ou não. Esta informação é provida pela camada deNET.
O bit de RS do mestre de célula sempre é 1.RSD, Reservado:
Não usado no momento. Este campo deve ser reguladopara O.
CD, Grau de Conectividade:
Este campo indica o grau de conectividade do nó comseus pais. Dependendo do número de pais de SYNC potenciaisque o nó tiver, o grau de conectividade assume um valordiferente.
O valor de CD do mestre de célula sempre é reguladopara 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 nível do remetente. Um transmissorde nível 0 sinaliza que o transmissor não está conectado àrede de malha. Um transmissor de nível 1 indica que otransmissor é um mestre de célula. Para o outro valor, se ηfor o número de saltos para atingir o mestre de célula, onível será definido por LVL=n+l.
GPD, Atraso de propagação global:
Este campo indica o atraso de propagação global entreo remetente e o mestre de célula.
SACT, Temporizador de contagem regressiva de Aloha comintervalo:Este campo indica o tempo remanescente antes de oponto final comutar para o próximo intervalo de tempo,quando o transmissor envia a mensagem. 0 SACT é expresso emMAC_SACT__Resolution ps.
TSN, Número de intervalo de tempo:
Este campo proporciona o número de intervalo de tempono qual a mensagem é enviada. Combinado com o endereço decélula (CELL), qualquer ponto final pode deduzir o canaldeste intervalo de tempo.
CELL, Endereço de célula:
Este campo proporciona o endereço da célula com a qualo ponto final está sincronizado. Estes 2 bytes são usadospara a computação da seqüência de salto de freqüência usadana célula. Em um sinal de orientação de descoberta, estecampo é usado para a especificação da célula preferida emuma partida a quente. O endereço de camada de eletrodo ébaseado no endereço C12.22 da placa de WAN de relê decélula.
FID, ID de quadro:
O ID de quadro é incrementado e enviado em cadarequisição de Sync e dados de monodifusão; ele é enviado no(N)ACK ou SYNC_(N)ACK para especificação do pacote a queele está respondendo.
OID, ID de falta:
0 número de falta do ponto final que experimenta umafalta de potência.
DA, Endereço de destino:
0 endereço de destino é de 4 bytes de comprimento.
HFN, Número de hiperquadro:
O número de hiperquadro pode ser usado de váriasformas, dependendo do tipo de mensagem.
RITP, ITP relativo:
0 ITP relativo é propagado na rede através de um tipodedicado de mensagem. Este é a estampa de tempo de ITP docomeço do número de hiperquadro 0.
RxC, Canal de recepção:
Este campo indica o número de canal no qual o EPouvirá durante a janela de escuta da fase de descoberta.NDB, Número de sinais de orientação de descobertaremanescentes:
Ele proporciona o número de sinais de orientação dedescoberta remanescentes a enviar antes do começo da janelade escuta.
O corpo de quadro está presente apenas em uma mensagemde 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 campoporta 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ãoalocados para um valor CRC-32 para a verificação daintegridade do cabeçalho de MAC e do corpo de quadro.
Os sinais de orientação são mensagens vazias sem umdestino específico. Eles contêm apenas uma informação desincronização; um ponto final envia sinais de orientaçãoperiodicamente quando ele não gera qualquer outro tráfego.0 comprimento de sinal de orientação no nível de MAC é de19 bytes, conforme representado graficamente na Figura 37.
Uma requisição de SYNC é enviada por um ponto finalque quer se tornar sincronizado com um outro. O campo deFID é um contador, incrementado em cada Requisição de SYNCou Dado de Monodifusão enviado. 0 comprimento de requisiçãode SYNC no nível de MAC é de 24 bytes, conformerepresentado graficamente pela presente Figura 38.
Os tipos a seguir de mensagens são usados parareconhecimento ou não de mensagens de dados e requisiçõesde SYNC. 0 campo de FID difere do FID da mensagem a qual é(não) reconhecida. O comprimento de (N)ACK ou SYNC NACK nonível de MAC é de 24 bytes, conforme representadograficamente pela presente Figura 39.
Uma mensagem de SYNC ACK é um reconhecimento de umarequisição de SYNC. 0 campo de FID se refere ao FID damensagem de requisição de SYNC a qual é reconhecida. Eladifere de SYNC NACK porque o número de hiperquadro atual,HFN, e o ITP relativo deste hiperquadro também sãotransmitidos. 0 comprimento de SYNC ACK no nível de MAC éde 29 bytes, conforme representado graficamente pela Figura40. Uma nota especial é que esta mensagem não se ajusta emum único subintervalo de tempo (para 1 byte).
Se um ponto final precisar atualizar a informação desincronização de um de seus vizinhos ou apenas checar seele ainda está presente, ele poderá enviar um sinal deorientação de requisição. 0 comprimento de sinal deorientaçã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 dedados enviada apenas para um destino. Ela contém o corpo dequadro que a LPDU porta. 0 campo de FID é um contador,incrementado em cada requisição de dados de monodifusão ouSYNC enviada. O comprimento de quadro de MAC de monodifusãoé de comprimento de LPDU + 24 bytes, conforme representadograficamente pela Figura 42.
A difusão é uma mensagem de dados não endereçada aqualquer um em particular, mas pretendida para qualquerponto final recebendo-a. o comprimento de quadro de MAC dedifusão é de comprimento de LPDU + 19 bytes, conformerepresentado graficamente pela Figura 43.
As mensagens de ITP são mensagens dedicadas,inicializadas pelo mestre de célula, para a propagação doRITP na célula inteira. Elas são consideradas comomensagens de dados de difusão sem um corpo de quadro. Ocampo de RITP é fixado pelo mestre de célula, quando eleinicializa a mensagem, como o campo de HFN, o qual é onúmero de hiperquadro da criação do RITP. Quando os EPsencaminham a mensagem de ITP, eles mantêm os mesmos camposde HFN e RITP que aqueles criados pelo mestre de célula. Ocomprimento de ITP no nível de MAC é de 24 bytes, conformerepresentado graficamente pela Figura 44.
O sinal de orientação de descoberta é uma mensagemcurta enviada durante a fase de descoberta por EPs nãosincronizados. O campo RxC indica o canal de escuta da fasede descoberta, NDB o número de sinais de orientação dedescoberta remanescentes a enviar antes da janela deescuta, e CELL é regulado para o endereço de célula com queo nó deseja se sincronizar, em uma partida a quente(regulado para 0 em uma partida a frio) . O comprimento desinal de orientação de descoberta no nível de MAC é de 13bytes, conforme representado graficamente pela Figura 45.
As mensagens de falta são as mensagens mais simples emais curtas que podem ser enviadas. Quando um ponto finalpercebe que há uma falta de potência, ele usa seu últimosuspiro para enviar várias destas mensagens. 0 OIDproporciona o número de falta. Em cada nova falta, o EPincrementa este número de falta, o qual rola em um 1 byte.
Para cada falta, três mensagens de falta são enviadasrandomizadas em três intervalos de 5 segundos (o OID fica omesmo para estes três pacotes). 0 comprimento de mensagemde falta no nível de MAC é de 10 bytes, conformerepresentado graficamente pela Figura 46.
A presente Figura 47 representa esquematicamente osServiços de Camada de MAC, os quais refletem umafuncionalidade vantajosamente provida pelo presente assuntode protocolo. Especificamente, com um objetivo de enviaruma 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 acamada de LLC requisitando que a camada de MAC envie umamensagem para um vizinho. A mensagem é enviada com regrasde gerenciamento de tráfego padronizadas. Note que ovizinho 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 deentrada requisitados: LPDU. A operação pode ser descritacomo a camada de LLC requisitando que a camada de MAC envieuma mensagem para todo mundo na vizinhança. A mensagem éenviada com as regras de gerenciamento de tráfegopadronizadas.
Com o objetivo de enviar uma estampa de tempo de RITP,MAC_Request_Send_ITP, não há argumentos de entradarequisitados. A operação pode ser descrita como a camada deNET 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 umaMAC_Request_Send_Broadcast, exceto pelo fato de não haveruma LPDU a portar. Ao invés da LPDU, o MAC adiciona em seucabeçalho o RITP e o HFN da criação deste RITP. A mensagemé enviada com as regras de gerenciamento de tráfegopadronizadas.
Com um objetivo de medir o nível de interferênciamédio em um canal especificado e sua função deautocorrelação de tempo,MAC_Request_Environment_Analysis_Auto-Correlation, há umuso dos argumentos de entrada requisitados: Número de canal(Channel number), Número de amostras (Number of samples). Aoperação pode ser descrita como a camada de APIrequisitando, por meio das camadas de LLC e de NET, que acamada de MAC meça o RSSI em um canal especificado, um dadonúmero de vezes. A camada de MAC então computará o valormédio deste RSSI, bem como sua função de autocorrelação. Ataxa de aquisição de amostragem do RSSI é um parâmetro deMAC, MAC_RSSI_Sampling_Rate. Os valores dos atrasos para acomputação da função de autocorrelação são dados por umoutro parâmetro de MAC, MAC_RSSI_AF_Delays.
Com um objetivo de medir o nível de interferênciamédio de três canais especificados e sua função densidadede probabilidade, MAC_Request_Environment_Analysis_PDF, háo uso dos argumentos de entrada requisitados: Channelnumbers (3), RSSI_PDF_Max_Count (valor máximo de contadoresde intervalo (bin) ). A operação pode ser descrita como acamada de API requisitando, por meio das camadas de LLC eNET, que a camada de MAC meça o RSSI em três canaisespecificados tomados da seqüência de salto. Para cada umdestes canais, a camada de MAC computará a função densidadede probabilidade (PDF) de RSSI. O processo de aquisiçãopára quando um contador de intervalo (bin) atinge o valormáximo admitido para aquela requisição.
Com um objetivo de proporcionar ã camada de MAC ainformação quanto a se uma célula está autorizada ou não,MAC_Request__Cell_Authorization, há o uso dos argumentos deentrada requisitados: endereço de célula, status de célula.
A operação pode ser descrita como a camada de NETproporcionando, por meio da camada de LLC, para a camada deMAC o status de uma célula. Este pode ser autorizado ouproibido.
Com um objetivo de proporcionar à camada de MAC ainformação quanto a se a camada de NET está registrada,MAC_Request_Cell_Registration, há o uso dos argumentos deentrada requisitados: endereço de célula, status deregistro. A operação pode ser descrita como a camada de NETinformando, por meio da camada de LLC, o status de registrode NET na célula. Então, a camada de MAC pode regular o bitde RS (estado registrado) para 0 ou 1 em seu cabeçalho.
Com um objetivo de responder a umaMAC_Request_Send_Mono_Data,
MAC_Confirmation_Send_Mono_Data, há o uso dos argumentos desaída requisitados: status da mensagem (ACK, NACK, NenhumACK). A operação pode ser descrita como se proporcionando àcamada de LLC o status de uma Requisição de Enviar Dados deMono. Cada confirmação é ligada ao número da requisiçãoassociada, para se evitar uma confusão. A confirmação podeser um ACK ou um NACK, se essas mensagens tiverem sidorecebidas, ou um status de Nenhum ACK, se o destino nãotiver respondido no intervalo de tempo em que deveria.
Com um objetivo de responder a umaMAC_Request_Send_Broadcast e MAC_Request_Send_ITP,MAC_Confirmation_Send_Broadcast eMAC_Confirmation_Send_ITP, há o uso dos argumentos de saídarequisitados: Status. A operação pode ser descrita como seconfirmando para a LLC quando a difusão ou o ITP foienviado. Então, a LLC pode prosseguir para a repetição, senecessário.
Com um objetivo de responder a umaMAC_Request_Environment_Analysis_Auto-Correlation,MAC_Confirmation_Environment_Analysis_Auto-Correlation, háo uso dos argumentos de saída requisitados: RSSI médio,valores de função de autocorrelação de RSSI. A operaçãopode ser descrita como a camada de MAC enviando para acamada acima o valor médio de RSSI e os valores da funçãode autocorrelação computados durante a análise ambientalrequisitada. O número de valores para a função deautocorrelação é o número de atrasos em que esta função foicalculada. Estes atrasos são definidos pelo parâmetro decamada de MAC MAC_RSSI_AF_Delays.
Com um objetivo de responder a umaMAC_Request_Environment_Analysis_PDF,MAC_Confirmation_Environment_Analysis_PDF, há o uso dosargumentos de saída requisitados: valores de PDF de RSSIpara os três canais requisitados (3 χ 24 valores). Aoperação pode ser descrita como a camada de MAC enviandopara a camada acima os valores de PDF de RSSI (realmente,os valores dos contadores de intervalo (bin) para cada umdos três canais requisitados.
Com um objetivo de responder a uma
MAC_Request_Cell_Autorization,
MAC_Confirmation_Cell_Authorization, há o uso dosargumentos de saída requisitados: Status. A operação podeser descrita como apenas se confirmando que a requisiçãofoi levada em consideração.
Com um objetivo de responder a uma
MAC_Request_Cell_Registration,
MACConfirmation_Cell_Registration, há o uso dos argumentosde saída requisitados: Status. A operação pode ser descritacomo apenas se confirmando que a requisição foi levada emconsideração.
Com um objetivo de encaminhar uma mensagem de LPDUrecebida para a camada de LLC, MAC_Indication_Received, háo uso dos argumentos de saída requisitados: LPDU, endereçode remetente. A operação pode ser descrita como seproporcionando à camada de LLC a LPDU que foi recebida como endereço de remetente.
Com um objetivo de informar que uma mensagem de ITP dedifusão foi recebida, MAC_Indication_ITP_Received, não há ouso de quaisquer argumentos de saída. A operação pode serdescrita como quando uma mensagem de ITP de difusão válidaé recebida, a camada de MAC atualiza o campo de RITP einforma à camada de NET, por meio da camada de LLC, aquelachegada. O resultado desta indicação força a camada de NETa 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ídarequisitados: estampa de tempo de ITP absoluta. A operaçãopode ser descrita como o RITP podendo ser atualizado após arecepção de uma mensagem de difusão ou de um SYNC ACK. Acamada de MAC então computa uma atualização do ITP absolutoe a envia para a camada de API. Assim que o ITP sejacomputado, ele deve ser proporcionado à camada de API muitorapidamente. Esta indicação tem prioridade em relação atodas as outras indicações.
Com um objetivo de indicar para a camada acima oestado de MAC, MAC_Indication_State, há o uso dosargumentos de saída requisitados: estado, endereço decélula. A operação pode ser descrita como a camada de MACinformando às camadas superiores após cada modificação deestado. A camada de MAC pode ser não sincronizada ousincronizada com uma célula. No último caso, o endereço dacélula é indicado.
Com um objetivo de indicar para a camada acima que acamada de MAC logo deixará a célula atual,MAC_Indication_Cell_Leaving_process, não há o uso dequaisquer argumentos de saída. A operação pode ser descritacomo a camada de MAC informando às camadas superiores queela descobriu uma nova célula e deixará logo aquela atual.
Com um objetivo de informar que uma notificação defalta de potência foi recebida,MAC_Indication_Outage_Received, há o uso dos argumentos desaída requisitados: ID de falta, endereço de remetente,tempo de falta. A operação pode ser descrita como sendoindicado para a camada de Net, por meio da LLC, que umvizinho experimentou uma falta em um dado tempo. Ela forçaa camada de NET a encaminhar esta notificação para o mestrede célula.
A camada de MAC é organizada em três modos: o modo nãosincronizado, o modo de sincronização e o modosincronizado. Quando um medidor é comutado para ligado ouapós um blecaute, a camada de MAC vai para o modo nãosincronizado. A presente Figura 4 8 representa essesrecursos e outros aspectos, incluindo uma exposiçãoadicional referente ao assunto de diagrama de estado de MAC.
A camada de controle de enlace lógico é a segundasubcamada da camada de enlace de dados, seguindo-se àcamada de Net. Sua meta é prover outras funcionalidades quepodem operar independentemente acima daquelas da camada deMAC, mas ainda têm a meta de otimização do acesso ao meio.
Alguns serviços providos pela camada de MAC sãoinúteis sem a camada de LLC, ao invés disso eles sendopretendidos para as camadas acima da camada de enlace dedados, tal como a camada de NET. Portanto, de modo a nãoromper a abordagem de camada, alguns serviços são meramenteencaminhados a partir da MAC para a camada de NET, e vice-versa, passando através da camada de LLC como se ela fosseum tubo.
A listagem a seguir descreve os parâmetros ajustáveis(isto é, passíveis de tweak) da camada de LLC com seusvalores padronizados preferidos associados sendoreferenciados na presente Figura 49.
LLC_Duplicatíon_Table_Size
Descrição: O número de entradas de mensagens de LLCsalvas na memória para se evitarem mensagensduplicadas, quando o mesmo pacote é recebido váriasvezes.
LLC_Ma.x_Messa.ge_Len.gth
Descrição: 0 comprimento de mensagem máximo que acamada 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_Length = LLC_Max_Packet_Length *LLC_Max_Nb_of_PacketsLLC_Max_Nb_of_Packets
Descrição: O número máximo de pacotes em que a LLCpode fragmentar uma mensagem.
LLC_Max_Nb_of_Downlink_Transmissions:
Descrição: O número máximo de vezes que um pacote deenlace descendente deve ser enviado, se nenhumreconhecimento for recebido.
LLC_Max_Nb_of_Uplink_Transmissions:
Descrição: O número máximo de vezes que um pacote deenlace ascendente deve ser enviado, se nenhumreconhecimento for recebido.
LLC_Max_Packet_Length
Descrição: O comprimento de pacote de NETPDU máximoque a camada de LLC permite que a camada superiorenvie em um intervalo de tempo.
Comentário: LLC_Max_Packet_LengthMAC_Max_Packet_Length - LLC_Header_LengthLLC_Message_Timeout
Descrição: Especifica um limite de tempo para atransmissão / recepção de uma mensagem fragmentada.
LLC Nb of Broacast TransmissionsDescrição: O número de vezes que uma difusão é enviadaLLC_Tx_Retry_Exp_Offset
Descrição: Este parâmetro controla a inclinaçãoinicial da lei de período de retorno após colisãoexponencial para a repetição.
LLC_Tx_Retry_Exp_Range
Descrição: Isto é usado para a computação do número derepetição a partir do qual a lei de período de retornoapós colisão exponencial binária é truncada.
LLC_Tx_Retry_Exp_Start
Descrição: O número de repetição a partir do qual alei de período de retorno após colisão exponencialbinária é aplicada para uma computação de janela derandomização de nova tentativa de transmissão.
Comentário: Este valor deve ser menor do que o númeromáximo de transmissões para pacotes de enlaceascendente e de enlace descendente para que o períodode 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 deLLC deve ser reconhecida no nível de camada de MAC. Muitofreqüentemente calhará de a camada de MAC reportar que elanão recebeu este reconhecimento. Isto pode ocorrer se oponto final de destino falhar em receber a mensagem ou se oremetente falhar em receber o reconhecimento, devido acolisões, interferência ou desvanecimento. Em qualquer casode falha, a camada de LLC enviará a mensagem de novo atéser reconhecida ou até o número máximo de tentativas seratingido. Após LLC_Max_Nb_of_Downlink_Transmissions ousucedidas, a camada de LLC reporta um status de falha deNo-ACK para a camada de NET.
Para dados de difusão ou ITP, a LLC automaticamenterepetirá a mensagem até o algoritmo de período de retornoapós colisão, uma vez que a camada de MAC tenha notificadoque o envio anterior se foi e isto até o númeroespecificado de tentativas,
Number_of_Broacast_Transmissions, ser atingido.
Quando a camada de LLC recebe a partir da camada deNET uma requisição para enviar um pacote, ou quando elareprograma uma transmissão não reconhecida, ela introduziráum atraso randômico antes de realmente enviar a requisiçãopara a camada de MAC. A finalidade deste atraso é evitarinundar a interface de ar com um grande número de pacotes,quando as condições de transmissão forem difíceis. A camadade MAC computará o comprimento de uma janela derandomização, Tx_Wait, e enviará a requisição real para acamada de MAC, após um atraso randômico, com umadistribuição de probabilidade uniforme entre 0 e Tx_Wait. 0valor de Tx_Wait é computado como uma função do número derepetição. Tx_Wait é computado de acordo com uma lei deperíodo de retorno após colisão exponencial bináriatruncada, 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áximodado por (LLC_Max_Nb_of_Transmisions - 1) . A aplicaçãodesta lei de período de retorno após colisão exponencial éatrasada e truncada, conforme pode ser visto a partir daequação acima. Isto também é ilustrado pela presente Figura50, a qual representa graficamente o período de retornoapós colisão exponencial binário truncado atrasado paranovas tentativas de transmissão, se os pacotes não foremreconhecidos. O raciocínio por trás disto é simples e podeser explicado da forma a seguir. No período de "sem tempode espera", o transmissor está tentando canais diferentespara se evitar uma interferência ou condições de propagaçãodifíceis. No "período de retorno após colisão exponencialbinário", o transmissor está progressivamente aumentando otempo de espera para permitir que a rede se recupere decondições não usualmente difíceis (quaisquer que elassejam). 0 "período de retorno após colisão exponencialtruncado" é necessário para se evitar a introdução detempos de espera longos de forma não realista no sistema.
0 começo e o fim da lei de período de retorno apóscolisão exponencial binário são dados por dois parâmetrosde camada de LLC:
<formula>formula see original document page 273</formula>
Um parâmetro adicional introduz um desvio na aplicaçãoda lei exponencial e proporciona uma forma de controle dainformação inicial:
<formula>formula see original document page 273</formula>
0 exemplo a seguir ilustra o algoritmo de janela derandomizaçã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 detransmissão inicial.
<formula>formula see original document page 274</formula>
Se um pacote for reconhecido negativamente (NACK), afase "sem tempo de espera" da estratégia de retransmissãodeve ser desviada, porque, neste caso, nós sabemos que oque aconteceu não é devido a um problema de propagação ouinterferência (veja o apêndice). Por razões similares, nocaso especial de transmissão de difusão, o período deretorno após colisão exponencial não atrasado deve serusado. As difusões geram uma rajada de tráfego e colisõesinternas entre nós da rede têm probabilidade de ocorrerem edesaceleram a difusão. 0 uso imediato de um período deretorno após colisão exponencial pode mitigar esteproblema. Veja também a presente Figura 51, a qualrepresenta graficamente um período de retorno após colisãoexponencial binário truncado para novas tentativas detransmissão, se os pacotes forem reconhecidosnegativamente. Nestes casos, a lei de repetição é dada por:
<formula>formula see original document page 274</formula>
Se este pacote não for reconhecido e reconhecido maistarde negativamente em uma tentativa de transmissãosubseqüente, a lei de nova tentativa para pacotesreconhecidos negativamente deve ser aplicada. Da mesmaforma, se um pacote foi reconhecido negativamente e umanova tentativa mais tarde não for reconhecida, a lei denova tentativa para pacotes reconhecidos negativamentedeverá 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úmerode colisões, a camada de LLC pode enviar uma mensagem maisde uma vez, e também receber o mesmo pacote várias vezes.Para se evitar encaminhar a mensagem recebida para a camadade NET várias vezes, cada pacote transmitido tem um númerode LLC, LLC FID. Veja a presente Figura 52 para um exemplode uma Tabela de Duplicação de LLC. Devido a este número, acamada de LLC sabe se o pacote já foi recebido. Caso issoaconteça, o pacote é descartado.
Em cada nova recepção, o número de mensagem, o númerode pacote e o endereço de remetente são salvos em um FIFO,o qual contém as propriedades dasLLC_Duplication_Table_Size últimas mensagens. Então, aentrada mais antiga é substituída pela nova, caso já nãoesteja presente na tabela. Se uma mensagem duplicada forrecebida, a entrada existente associada na tabela precisaráser removida e reescrita como uma nova entrada. Istoassegurará que esta entrada permaneça mais tempo na tabela.
Deve ser notado que na recepção de uma mensagem, adetecção de pacotes duplicados deve ser feita antes daoperação de reconstituição de uma mensagem fragmentada.
Se o nó perder a sincronização, comutar para uma outracélula ou experimentar uma falta de potência (isto poderiaser feito na ativação), a tabela de duplicação será limpa.
Um outro serviço oferecido pela camada de LLC é afragmentação de mensagens. A camada de LLC oferece a camadasuperior para enviar mensagens de extensão de atéLLC_Max_Message_Length bytes, um tamanho que pode ser maislongo 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 damemória de dispositivo que roda o protocolo e pelo fato dea camada de LLC não puder lidar com mais de 15 pacotes.
Se a camada de NET pedir para enviar uma mensagemmaior do que a camada de MAC pode enviar, a camada de LLCdividirá a mensagem em vários pacotes mais curtos. 0 númerode pacote e o número de pacotes são mencionados nocabeçalho de LLC para se permitir a reconstituição damensagem inteira na recepção.
Cada pacote corresponde a uma requisição individualenviada para a camada de MAC. A camada de MAC treta estespacotes como mensagens completas regulares.
A camada de LLC computa o número requerido de pacotes,dependendo do comprimento de mensagem e do tamanho máximocom que a camada de MAC pode lidar.
A partir de uma perspectiva de lado de transmissor, acamada de LLC divide a mensagem em pacotes. Uma requisiçãode MAC é associada a cada pacote. Quando o primeiro pacoteé enviado, um contador de expiração do comprimento deLLC_Message_Timeout é começado. Cada pacote pode serenviado várias vezes, com a mesma limitação de repetiçãoque para um pacote padrão, até o pacote ser reconhecidopela camada de MAC. Quando todos os pacotes tiverem sidoreconhecidos, a camada de LLC confirma para a camada de NETque a mensagem foi enviada com sucesso. Se um pacote nãotiver sido enviado corretamente ou se o contador atingirLLC_Message_Timeout, a camada de LLC informará a camada deNET que a transmissão falhou.
Da perspectiva do lado de receptor, a camada de LLC dereceptor quando recebe o primeiro pacote de uma mensagemfragmentada, começa o mesmo contador de comprimento deLLC_Message_Timeout que aquele do lado de transmissor.Quando todos os pacotes tiverem sido recebidos, a camada deLLC gera de novo a mensagem inteira e a dá para a camada deNet. Se o contador atingir o valor LLC_Message_Timeout epelo menos um pacote ainda estiver faltando, todos osoutros pacotes serão apagados.
0 valor de LLC_Message_Timeout deve ser longo obastante para deixar a camada de MAC enviar corretamentetodos os pacotes. O valor pode depender do número de pacotea enviar.
O presente assunto de protocolo oferece um tipo deserviço de difusão, ou, mais especificamente, uma demultidifusão. A função é que a mesma mensagem possa serenviada para todos os pontos finais de uma célula. Isto éuma difusão verdadeira, a qual não é reconhecida, massimplesmente transmitindo Number_of_Broacast_Transmissionsvezes por cada ponto final. Pretende-se que qualquer pontofinal a ouça (exceto o mestre de célula, onde as difusõesse originam).
O cabeçalho de LLC é de 3 bytes de comprimento,conforme representado pela presente Figura 53, a qual deoutra forma representa o quadro de LLC pleno. Nessarepresentação, a informação de quadro adicional a seguir éaplicável, conforme será entendido por alguém deconhecimento comum na técnica, sem uma explicação detalhadaadicional.
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 evitaruma duplicação de um pacote.
NOP, Número de Pacotes:
Estes 4 bits proporcionam o número de pacotes que têmque ser transmitidos para a reconstrução dos dados.Isto implica que o protocolo pode dividir mensagens emum máximo de 15 pacotes.
PN, Número de Pacote:
Estes 4 bits proporcionam o número de pacote dos dadosfragmentados. 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 eserviços associados (funcionalidade), conforme representadoem detalhes pela presente Figura 54. A camada de LLCassegura uma funcionalidade confiável, não apenas de simesma, mas nos serviços que prove para aqueles em relaçãocom ela, tal como resultando em a camada de LLC gerenciar arepetição e a fragmentação de mensagens. Por exemplo,dependendo de (não) reconhecimentos, a camada de LLCescolhe se o pacote tem que ser retransmitido ou não.
Com um objetivo de enviar uma mensagem para umdestino, LLC Request Send Mono Data, há o uso de argumentosde entrada requisitados: NETPDU, e Endereço de destino. Aoperação pode ser descrita como a camada de NETrequisitando que a camada de LLC envie uma mensagem para umde seus vizinhos. A camada de LLC fragmenta a mensagem emvários pacotes, se necessário, para se proporcioná-la paraa camada de MAC. A camada de LLC também tenta enviar amensagem várias vezes, antes de reportar um sucesso ou umerro para a camada de NET.
Com um objetivo de enviar uma mensagem para avizinhança, LLC_Request_Send_Broadcast, há o uso deargumentos de entrada requisitados NETPDU. A operação podeser descrita como a camada de NET requisitando que a camadade LLC envie uma mensagem para todos os vizinhos de pontofinal. A camada de LLC fragmenta a mensagem em váriospacotes, se necessário, para se proporcioná-la para acamada de MAC. A difusão é repetidaNumber_of_Broacast_Transmissions vezes.
Com um objetivo de enviar uma estampa de tempo de RITPpara a vizinhança, LLC_Request_Send_ITP, não há o uso deargumentos. A operação pode ser descrita como a camada deNET requisitando que a camada de LLC envie uma mensagem deITP para todos os vizinhos de ponto final. Esta requisiçãosegue a mesma abordagem que uma LLC_Request_Send_Broadcast,exceto pelo fato de não haver nem NETPDU, nem LPDU. A LLCencaminha a requisição para a camada de MAC, a qual estáencarregada da estampa de tempo da mensagem. A camada deLLC gerencia a repetição desta mensagem como uma difusãoregular.
Com um objetivo de medir o nível de interferênciamédio em um canal especificado e sua função deautocorrelação, LLC_Request_Environment_Analysis_Auto-Correlation, há o uso de argumentos de entradarequisitados: Número de canal, Número de amostras. Aoperação pode ser descrita como uma requisição sendoencaminhada para a camada de MAC.
Com um objetivo de medir o nível de interferênciamédio em três canais especificados e sua função densidadede probabilidade, LLC_Request_Environment_Analysis_PDF, háo uso de argumentos de entrada requisitados: Números decanal (3), valor máximo de contador. A operação pode serdescrita como sendo uma requisição encaminhada diretamentepara a camada de MAC.
Com um objetivo de proporcionar para a camada de MAC ainformação quanto a se uma célula está autorizada ou não,LLC_Request_Cell_Authorization, há o uso de argumentos deentrada requisitados: Endereço de célula, Status de célula.A operação pode ser descrita como uma requisição sendoencaminhada diretamente para a camada de MAC.
Com um objetivo de proporcionar para a camada de MAC ainformação quanto a se a camada de NET está registrada,LLC_Request_Cell_Registration, há o uso de argumentos deentrada requisitados: Endereço de célula, Status deregistro. A operação pode ser descrita como uma requisiçãosendo encaminhada diretamente para a camada de MAC.
Com um objetivo de responder a umLLC_Request_Send_Mono_Data,LLC Confirmation_Send_Mono_Data, há o uso de argumentos desaída requisitados: ACK, NACK, Nenhum ACK, Endereço dedestino do pacote enviado. A operação pode ser descritacomo se confirmando para a camada de NET se a mensagem foienviada com sucesso para o destino ou não. Caso não e sepelo menos um NACK tiver sido recebido, deve ser notificadopara a camada de NET. A camada de NET então é capaz deescolher se ela tem que transmitir o pacote para um outrodestino. Mediante o recebimento de uma confirmação de falhapara uma mensagem de enlace ascendente, a camada de NETatualizará suas probabilidades de roteamento e enviará umanova requisição para o LLC.
Com um objetivo de responder a umLLC_Request_Send_Broadcast e LLC_Request_Send_ITP,LLC_Confirmation_Send_Broadcast e
LLC_Confirmation_Send_ITP, há o uso de argumentos de saídarequisitados: OK. A operação pode ser descrita como seconfirmando para a camada de NET que a difusão foi enviada.
Com um objetivo de responder a umLLC_Request_Environment_Analysis_Auto-Correlation,LLC Confirmation_Environment_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çãopode ser descrita como um encaminhamento deMAC_Confirmation_Environment_Analysis_Auto-Correlation apartir da camada de MAC para a camada de NET.
Com um objetivo de responder a umLLC_Request_Environment_Analysis_PDF,
LLC_Confirmation_Environment_Analysis_PDF, há o uso deargumentos de saída requisitados de valores de PDF de RSSIpara os três canais requisitados (3 χ 24 valores) . Aoperação pode ser descrita como um encaminhamento de umMAC_Confirmation_Environment_Analysis_PDF a partir dacamada de MAC para a camada de NET.Com um objetivo de responder a umLLC_Request_Cell_Autorization,
LLC_Confirmation_Cell_Authorization, há o uso de argumentosde saída requisitados: Status. A operação pode serdescrita como um encaminhamento de
MAC_Confirmation_Cell_Authorization a partir da camada deMAC para a camada de NET.
Com um objetivo de responder a umLLC_Reque s t_Ce1l_Regi s trat ion,
LLC_Confirmation_Cell_Registration, há o uso de argumentosde saída requisitados: Status. A operação pode serdescrita como um encaminhamento de
MAC_Confirmation_Cell_Registration a partir da camada deMAC para a camada de NET.
Com um objetivo de encaminhar uma mensagem de NETPDUrecebida para a camada de NET, LLC_Indication_Received, háo uso de argumentos de saída requisitados: NETPDU, Endereçode remetente. A operação pode ser descrita como após amontagem de todos os pacotes, se a mensagem tiver sidofragmentada, a camada de LLC proporcionar a mensagem deNETPDU para a camada de NET.
Com um objetivo de informar que uma material deedificação de ITP foi recebida,LLC_Indication_ITP_Received, não há o uso de quaisquerargumentos de saída. A operação pode ser descrita como umencaminhamento direto da MAC_Indication_ITP_Received apartir 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ídarequisitados: Estampa de tempo de ITP absoluta. A operaçãopode ser descrita como um encaminhamento direto deMAC_Indication_ITP_Update a partir da camada de MAC para acamada de NET. Esta indicação tem prioridade em relação atodas as outras indicações.
Com um objetivo de indicar para a camada acima oestado de MAC, LLC_Indication_State, há o uso de argumentosde saída requisitados: Estado, Endereço de célula. Aoperação pode ser descrita como a camada de LLC obter estaindicação diretamente do MAC_Indication_State.
Com um objetivo de indicar para a camada acima que acamada de MAC logo deixará a célula atual,LLC Indication_Cell_Leaving_process, não há o uso dequaisquer argumentos de saída. A operação pode serdescrita como um encaminhamento direto deMAC_Indication_Cell_Leaving_process a partir da camada deMAC para a camada de NET. Antes de encaminhar, a camada deLLC libera seus buffers e suas ações pendentes
Com um objetivo de informar que uma notificação defalta de potência foi recebida,LLC_Indication_Outage_Received, há o uso de argumentos desaída requisitados: ID de Falta, Endereço de remetente,Tempo de falta. A operação pode ser descrita como umencaminhamento direto de MAC_Indication_Outage_Received apartir da camada de MAC para a camada de NET.
0 que vem a seguir se refere, mais particularmente, àcamada de rede (NET). A camada de rede é a terceira camadado modelo de OSI e a camada mais alta do protocolo Linknet.É o coração do mecanismo de roteamento. Todos os pontosfinais têm a mesma camada de rede, exceto pelo mestre decélula, o qual estendeu as funções de roteamento. Aprincipal tarefa da camada de NET é decidir qual é odestino das mensagens, mas também está encarregada doprocesso de registro de célula, o qual é interno à RF LAN.
Pelo recurso de camada de NET de EP (ponto final), acamada de NET encaminha qualquer mensagem para o próximosalto. Ela também prove dados sobre sua vizinhança para orelê de célula. Pela camada de NET de CR (relê de célula oumestre de célula) , a camada de NET se oferece para enviarpara um EP (mensagem de enlace descendente) em particularna célula ou para a célula inteira (mensagem de difusão). Acamada de NET de CR não se oferece para enviar uma mensagempara um conjunto especifico de EPs na célula. Também, acamada de rede está ativa apenas enquanto o ponto finalestiver sincronizado, e deixará a camada de aplicativo usara rede apenas se estiver registrada no nível de NET.
Os parâmetros de NET podem ser listados conforme sesegue, 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 emuma célula, em número de hiperquadros.NE T_CR_Down1ink_Duplication_Table_Size:
Descrição: 0 número de entradas de mensagem de enlacedescendente de NET salvo na memória de mestre decélula para se evitarem mensagens em duplicata deenlace descendente, quando recebidas várias mensagensde enlace rompido a partir do mesmo enlacedescendente.
NET_CRJDup1ication_Table_Siζe:
Descrição: O número de entradas de mensagem de NETsalvas na memória de mestre de célula para se evitaremmensagens em duplicata, quando o mesmo pacote forrecebido várias vezes.
NET_Down1ink_Life_Expectancy:
Descrição: O tempo de vida máximo de um enlacedescendente em uma célula, em número de hiperquadros.
NET_Endpoint_TimeOut:
Descrição: O tempo após o qual um ponto final deve serremovido 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 NETsalvas na memória de ponto final para se evitaremmensagens em duplicata, quando o mesmo pacote forrecebido várias vezes.
NET_Max_Registration_Attempts:
Descrição: O número máximo de tentativas de requisiçãode registro de célula que um ponto final pode enviarpara uma dada célula, antes de declarar esta célulacomo proibida.
NET_Max_Nb_of_EPs:
Descrição: O número máximo de pontos finais porcélula. Isto é útil para a camada de NET de mestre decélula, a qual pode decidir autorizar ou não um novoponto final em sua célula. Também é o tamanho databela de roteamento de mestre de célula.
NET_Nb_of_Fathers_Routing:
Descrição: Quando do roteamento de uma mensagem para omestre de célula, a camada de NET escolherá um paidentre um subconjunto constituído pelos melhores paispara um roteamento. 0 tamanho deste subconjunto éNET_Nb_of_Fathers_Routing.
NET_Nb_of_Endpoints_Neighbor_List:
Descrição: Corresponde ao número máximo de pontosfinais presentes em uma lista de vizinho.
NET_Neighbor_List_First_Time:
Descrição: 0 tempo após o qual um ponto final deveenviar sua primeira lista de vizinho para o mestre decé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 dalista de vizinho para o mestre de célula, se estalista não tiver mudado.
NET_Neighbor_List_Min_Period:
Descrição: o período mínimo entre duas transmissões dalista de vizinho para o mestre de célula, se estalista tiver mudado.
NET_Reg_Send_Config_Period:
Descrição: A taxa na qual o mestre de célula devetentar enviar as confirmações de registro queestiverem pendentes. Ela pode ser mais lenta, se obuffer de enlace descendente estiver cheio, mas nãodeve ser mais rápida.
NET_Registration_Retry:
Descrição: O período durante o qual um ponto finalestá esperando pela confirmação de registro para suaprimeira requisição. Após a primeira requisição, estetempo é multiplicado pelo número de tentativas derequisição para se obter o período de espera.NET_Regi stration_Send_Max:
Descrição: Este parâmetro define o limite máximo dajanela de randomização de NET na qual a requisição deregistro deve ser enviada.
NET_Registration_Send_Min:
Descrição: Este parâmetro define o limite inferior dajanela de randomização de NET na qual a requisição deregistro deve ser enviada.
NET_ Uplink_Life_Expectancy:
Descrição: o tempo de vida máximo de um enlacedescendente em uma célula, em número de hiperquadros.
Com respeito à assim denominada tabela de vizinho, acamada de rede usa a tabela de vizinho da camada de MAC comdireitos de leitura. Isto significa que a camada de redenão pode modificar os valores nessa tabela. A presenteFigura 55 descreve o assunto de VALORES PADRÕES DEPARÂMETRO DE CAMADA DE REDE.
Antes da autorização de camadas superiores para seusar a rede, um ponto final deve ser registrado em um nívelde camada de NET. 0 processo de registro de NET começaassim que o ponto final começa sua sincronização a partirda camada de MAC. Há duas formas de se proceder quanto a seo ponto final foi previamente registrado junto à célula, oque leva a um processo de partida a quente, ou se está seunindo a uma nova célula, o que leva a um processo departida a frio.
O comportamento durante este processo de registro decélula também pode ser visto a partir de dois lados, oponto final ou o mestre de célula.
No cenário de partida a frio, os eventos a seguirdevem acontecer, antes de a camada de API poder acessar arede:
A camada de MAC obtém uma sincronização comum de seus pais de SYNC potenciais e entra em umanova célula.
A camada de NET é informada do status desincronização e envia, randomicamente entreNET_Registration_Send_Min e
NET_Registration_Send_Max, uma requisição deregistro de célula para o mestre de célula.
Então, o ponto final está esperando pelaresposta:
1. Se não houver nenhuma resposta. Há ummecanismo de nova tentativa a cada (número denovas tentativas * NET_Registration_Retry) . Há ummáximo de NET_Max_Registration_Attemptstentativas de registro com esta célula, antes dedesistir; após isso, a célula é declarada comoproibida e a camada de MAC deve procurar por umaoutra célula (é lembrado que apósMAC_Unsynchronized_Timeout dias no modo dedescoberta, a camada de MAC reautorizará todas ascélulas).
Assim, com NET_Registration_Send_Min = 5min, NET_Registration_Send_Max = 10 min,NET_Registration_Retry = 1 hora, e
NET_Max_Registration_Attempts =5, as requisiçõesserã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 janelada próxima tentativa (ou aNET_Max_Registration_Attempts *
NET_Registration_Retry para a última tentativa;15 horas)
2. Se uma notificação de célula fora de NET forrecebida, a célula será imediatamente marcadacomo proibida e a camada de MAC procurará por umaoutra célula.
3. Se uma confirmação de registro de célula deNET for recebida, o ponto final comutará para oestado registrado de NET.
Uma vez que o ponto final seja registrado naNET:
1. A NET informa à camada de MAC que agoraregulará seu bit de RS para 1 em seu cabeçalho, oque significa que este ponto final agora pode serusado como um pai de SYNC para seus vizinhos.
2. A NET informa à camada de API que ela agoraestá autorizada a enviar mensagens através darede.
3. A camada de NET começa a enviarperiodicamente listas de vizinho (a requisição deregistro de célula é considerada como uma, demodo que a primeira lista de vizinho real sejaenviada após um período definido; isto é,NET_Neighbor_List_Min_Period hora, se nenhumamudança tiver ocorrido).
Vários itens em particular são de nota:
Em qualquer momento, se um ponto final receber umanotificaçã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 podeser 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 falarenquanto o ponto final ainda não tiver se registrado,o enlace ascendente com o tipo de pacote de lista devizinho nunca é usado. Contudo, esta definição depacote ainda é definida na especificação, já que podeser 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 seuspais de SYNC potenciais e recupera a célula na qualela foi apropriadamente registrada.
• A camada de NET vai diretamente para o estadoregistrado e informa às camadas de MAC e de API.
• A camada de NET começa enviando periodicamente listasde vizinho. Uma vez que nenhuma requisição de registrode célula, a qual contém uma informação de lista devizinho foi enviada, a primeira lista de vizinho éenviada após Neighbor_List_First_Time minutos.Quando um mestre de célula recebe uma requisição de
registro de célula, ele deve enviar uma confirmação deregistro de célula e atualizar sua tabela de roteamento coma nova informação (adicionar o ponto final se ele ainda nãoestiver ali), a menos que a tabela de roteamento estejacheia, em cujo caso ele deve enviar uma notificação desaída de célula. Para maiores detalhes sobre as ações de ummestre de célula quando recebendo um pacote, veja aexposição remanescente aqui.
Durante uma partida a frio, o mestre de célula estárecebendo uma grande quantidade de requisições de registrode célula em uma janela de tempo estreita. Portanto, elenão tem tempo suficiente para enviar toda a confirmação deregistro na mesma taxa em que recebe requisições. Como umaconseqüência, o mestre de célula deve manter umacompanhamento 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 demetade do tamanho de célula).
A lista de registro pendente pode ser manipulada pelaregulagem de um indicador tipo de flag na tabela deroteamento dos pontos finais correspondentes (1 bit *tamanho máximo de célula = 1 kb = 12 5 B) e periodicamentevarre a tabela para saber quais pontos finais precisam deuma confirmação de registro.
O registro pendente também deve ser feito como umalista de endereços a enviar uma confirmação; isto é umatransigência entre espaço de memória e tempo de execução decódigo e a escolha é deixada para a implementação.
Em ambos os casos, quando há muitas confirmaçõesempilhadas, elas devem ser enviadas a uma taxa máxima deNET_Reg_Config_Send_Period. É para assegurar não somos nósinundando a rede com mensagens de enlace descendente.
Quando um ponto final comutar de célula, ele seregistrará na nova célula. A questão é que ele ainda estáregistrado na célula antiga; isto não é uma questão pararoteamento, uma vez que o nível de API perceberá que oponto final se moveu de célula, mas isto pode ser umaquestão para gerenciamento de tamanho de célula.
Efetivamente, o indicador de tamanho de célula (CSI) usadono processo de comutação de célula é com base no número deponto final na tabela de roteamento de NET do mestre decélula e, se este número não refletir a realidade, então, oprocesso de comutação não funcionará mais apropriadamente.
É por isto que é importante que o mestre de célula antigoseja informado da partida de pontos finais de sua célula.
Este é o papel da mensagem de notificação de saída decélula.
Assim que a camada de MAC notifica que um vizinho deuma célula melhor é alcançável, ela planeja uma requisiçãode SYNC e espera pelo SYNC ACK. 0 SYNC ACK recebido, acamada 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 deMAC_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 omestre de célula atual. Esta mensagem permitirá queo mestre de célula remova o ponto final de suatabela de roteamento e atualize o tamanho de célula.
Durante MAC_CELL_Leaving_Process_Duration segundos, oponto final atua como usual, exceto pelo fato de não poderdecidir 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émencaminhar o mesmo tipo de informação de filhos os quaisdecidem por eles mesmos mudarem de célula (elesprovavelmente vêem a mesma nova célula ao mesmo tempo).
Quando o temporizador expira, qualquer que seja ostatus de mensagens remanescentes a enviar, a camada de MACressincroniza seu relógio e comuta para a nova célula. Acamada de LLC e a de NET são notificadas por estacomutaçã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 pontofinal na célula conhece sua vizinhança a 1 salto e não sabenada além do alcance de 1 salto. A situação é ligeiramentediferente para o mestre de célula e será explicada em umaseção dedicada.
O protocolo caracteriza duas direções de roteamentodiferentes, enlace ascendente e enlace descendente. 0enlace ascendente é usado para um medidor enviar umamensagem para o mestre de célula, e o enlace descendente éusado para o transporte de uma mensagem do mestre de célulapara um medidor. Estas duas direções de roteamento usammecanismos diferentes, conforme explicado abaixo.
Um outro mecanismo de roteamento é a difusão, usadapara o transporte de uma mensagem para todo ponto final dacélula.
Cada pacote que está indo através da camada de NETcontém uma estampa de tempo de quando ele foi gerado. Acada vez em que um pacote é roteado no nível de camada deNET, o tempo de vida do pacote é checado em relação a suaexpectativa de vida e é atrasado se for antigo demais.
Mais particularmente, para a realização de umacomunicação de enlace ascendente, o ponto final tem queenviar sua mensagem para o mestre de célula. O ponto finalnão sabe onde seu mestre de célula está, mas sabe que seuspais podem alcançá-lo. Portanto, ele tem que enviar amensagem de enlace ascendente para um de seus pais. 0protocolo deve limitar sua escolha para osNET_Nb_of_Fathers_Routing melhores pais, com base emSYNC_Merit. Ele deve selecionar randomicamente um destespais com uma probabilidade para cada pai inversamenteproporcional a seu SYNC_Merit e, então, enviar a mensagemde enlace ascendente para aquele pai. Todo pai sincronizadoe registrado da célula é adequado para um roteamento deenlace ascendente.
Se a LLC reportar uma transmissão com falha (apóstodas as novas tentativas), a camada de NET olhará de novona tabela de vizinho (a qual agora está atualizada deacordo com os resultados das tentativas prévias detransmissão), e selecionará de novo um pai randômico dentreos NET_Nb_of_Fathers_Routing melhores, usando o mesmoalgoritmo de seleção probabilístico como na primeirainstância. A mensagem de enlace ascendente então éencaminhada para a camada de LLC para transmissão para opai recém selecionado. Este processo continua até a LLCreportar uma transmissão bem sucedida ou até o ponto finalentrar em uma falha de potência, tornar-se dessincronizadoou comutar para uma nova célula.
Quando o pai selecionado receber esta mensagem deenlace ascendente, ele prosseguirá de uma forma similar.Este processo é repetido até o melhor pai ser o mestre decélula.
Antes de um pacote de enlace ascendente ser roteadopara um dos pais de ponto final, a camada de NET checa seele não é mais antigo do que NET_Uplink_Life_Expectancy. Seele 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 decélula para um ponto final especifico, é uma coisa muitofácil, ã medida que os pontos finais são concernidos. Defato, o percurso inteiro é indicado no cabeçalho de rede.Este percurso é especificado pelo mestre de célula, o qualtem um conhecimento completo de todos os pontos finais nacélula.
Quando um ponto final recebe uma mensagem de enlacedescendente, ele lê seu cabeçalho de rede e automaticamenteencontra o próximo destino a contatar. Isto é repetido atéo destino final ser atingido. Antes do encaminhamento damensagem para o próximo nó, o ponto final remove seupróprio endereço do percurso de roteamento do cabeçalho deNet. 0 ponto final deve encaminhar a mensagem para opróximo endereço no cabeçalho, mesmo se este endereço nãocombinar com qualquer nó em sua própria tabela de vizinho.
Antes de um pacote de enlace descendente serencaminhado para o próximo salto, a camada de NET checa seeste não é mais antigo do que NET_Downlink_Life_Expectancy.Se for mais antigo, então será apagado.
Se, por qualquer razão, o próximo nó não puder seratingido (após as novas tentativas de camada de LLC), amensagem tem que ser enviada de volta para o mestre decélula pelo percurso de enlace ascendente. Esta mensagem échamada uma mensagem de enlace interrompido. Uma mensagemde enlace rompido é composta por:
• A mensagem de enlace descendente original.
O endereço de destino final pretendido.
• A ID de quadro de NET da mensagem de mensagem deenlace descendente.
• Uma nova ID de quadro de NET para o enlaceinterrompido.
Os endereços do enlace faltando.
Será tarefa do mestre de célula encontrar um outropercurso, levando em consideração mudanças que tenhamocorrido nesse meio tempo. 0 mestre de célula entãoreenviará a mensagem de enlace descendente, se um percursopara 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 estamensagem de enlace descendente atingiu o destino final, eleterá que requisitá-la na camada de aplicativo.
Conforme citado mais tarde, a confirmação de registrode célula e a notificação de saída de célula são casosespeciais de pacotes de enlace descendente os quais nãogeram um enlace interrompido.
Uma mensagem de difusão é iniciada apenas no nível demestre de célula. Todos os pontos finais conectados àcélula devem receber a mensagem de difusão. De modo asimplificar esta operação pesada em uma célula grande, oprotocolo não garante que a mensagem seja entregue para100% dos pontos finais e não provê um reconhecimento nonivel de camada de rede. As camadas superiores devemgerenciar uma repetição da mensagem para aqueles que não atenham recebido. Isto pode ser feito pelo endereçamento damensagem para cada ponto final remanescente por um percursode 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 arepetição de si mesma).
A técnica de difusão é baseada no fato que cada pontofinal repete a mensagem de difusão umNumber_of_Broacas t_Transmi s s ions número de vezes, e cadaponto 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 vizinhostiver; este mecanismo permite uma boa cobertura da célula.
Note que o mestre de célula nunca deve aceitar uma mensagemde difusão, já que ele sempre as gera.
Um mecanismo de filtro é implementado no nivel decamada de rede para o envio apenas uma vez da mensagem dedifusão para a camada de aplicativo e também para seencaminhá-la uma vez. Um número de mensagem de difusão (NETFID) está contido no cabeçalho de NET para remoção demensagens que já tenham sido recebidas (o mesmo mecanismoque na camada de LLC). Com esta detecção de duplicação, adifusão não será repetida infinitamente na célula.
A detecção de duplicação funcionará desde que hajamenos difusões sendo encaminhadas na célula do que háespaços na tabela de detecção de duplicação. Istonormalmente seria o caso se a rede fosse usadaapropriadamente. Como uma salva-guarda, um mecanismo deexpiração foi adicionado. Na inicialização da rede, omestre de célula acessa o número de hiperquadro (HFN) atuale o insere no cabeçalho de NET. Quando um ponto final nacélula recebe esta difusão, ele sempre deve aceitá-la (apóschecar se não é uma duplicação) , mas apenas a retransmitese a difusão não for antiga demais, por uma comparação doHFN contido no cabeçalho com o HFN atual. O tempo de vidamáximo de uma difusão na célula é
NET_Broadcast_Life_Expectancy.
A camada de NET oferece um serviço não de duplicaçãopara:
• Caminho de enlace ascendente
o Enlace ascendente (com ou sem lista devizinho)
o Lista de vizinho
o Enlace interrompido
o Notificação de falta
• Difusão
Notificações de difusão e de falta podem serretransmitidas usando-se vários percursos na rede. Estaredundância contribui para uma melhor qualidade de entregade imagem. Mas também pode aumentar drasticamente aquantidade de tráfego. Para outras mensagens usando umesquema de modulação e de codificação de roteamento deenlace ascendente, uma duplicação também acontece, masmenos freqüentemente. Note que o percurso de enlacedescendente não é concernido aqui, já que não pode serduplicado. Usar este recurso de detecção de duplicação commensagens de enlace descendente mesmo degradará asperformances do serviço.
Para se evitar encaminhar a mensagem recebida váriasvezes para a camada de API ou para o próximo ponto final,cada mensagem transmitida tem um número de identificação deNET, NET FID ou NET OID. Devido a este número, a camada deNET sabe se o pacote já foi recebido. Caso isto aconteça, opacote 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 emuma tabela dedicada denominada a tabela de duplicação deNET (veja, por exemplo, a presente Figura 56). Esta tabelacontém as propriedades das NET_EP_Duplication_Table_Sizeúltimas mensagens e é gerenciada como um buffer de FIFO. Sea tabela estiver cheia quando uma nova mensagem chegar, aentrada mais antiga da tabela será lançada para fora,conforme a nova for introduzida na tabela. Se a novaentrada for idêntica a uma outra entrada na tabela, istoindicará que uma mensagem em duplicata foi recebida. Nestecaso, a cópia mais antiga é removida da tabela, conforme anova for introduzida na tabela. Desta forma, a informaçãopermanecerá mais tempo na tabela.
0 tamanho de tabela de duplicação de mestre de célulapode ser estendido para NET_CR_Duplication_Table_Size. Istoassegurará uma melhor filtração antes do encaminhamento demensagens para a camada de API, principalmente útil paranotificações de falta que podem ser muito numerosas em umperíodo de tempo curto. Para uma difusão (vindo do mestrede célula), o campo de endereço de remetente deve serregulado para zero. Para uma notificação de falta, oendereço de remetente deve corresponder ao endereço deremetente original especificado no campo de ORG. No caso emparticular de um enlace interrompido, o endereço deremetente é especificado no campo de BRKS. Se o nó perdersincronização, comutar para uma outra célula ouexperimentar uma falta de potência (isto pode ser feito naativação), a tabela de duplicação deverá ser limpa.
Com referência a uma lista de vizinho, se oconhecimento da vizinhança a um salto for suficiente paraum ponto final, este não será o caso para o mestre decélula. Este tem que conhecer o conteúdo da célula para acomputação dos percursos de enlace descendente. Portanto,todos os pontos finais devem enviar regularmente sua listade vizinho de NET usando uma mensagem de enlace ascendente.
A lista de vizinho é gerada a partir da tabela devizinho de NET. Ela consiste nos NET_Nb_ofEndpoints_Neighbor_List melhores pais, isto é, pais comSYNC_Merit mais baixo, representado por seus endereços deMAC. Os endereços de ponto final são classificados, omelhor aparecendo primeiro na lista. Esta informação ésuficiente para que o mestre de célula roteie pacotes paraqualquer ponto final especifico.
Como uma opção, se o número de pais presentes natabela de vizinho for inferior a NET_Nb_ofEndpoints_Neighbor_List, a lista de vizinho poderá sercompletada com os melhores irmãos (se eles forem válidospara roteamento de pacotes). Contudo, o algoritmo depercurso de enlace descendente deve ser inteligente obastante para detectar um percurso circular.
Apenas vizinhos sincronizados e registrados da célulapodem ser membros da lista de vizinho.
A primeira lista de vizinho é enviadaNET_Neighbor_List_First__Time após o ponto final se tornarsincronizado com uma célula para uma partida a quente, eNET_Neighbor_List_Min_Period para uma partida a frio.
As listas de vizinho devem ser atualizadas toda vezque um ponto final for removido da lista ou um novo pontofinal for adicionado à lista. As listas de vizinho entãosão enviadas em um período de NET_Neighbor_List_Min_Period,se uma mudança tiver ocorrido no período prévio. Se umponto final mudar de nível, isto deve criar um indicadortipo de flag que disparará a transmissão de uma lista devizinho no fim do período atual. Se um ponto final sofreruma comutação de célula, então, ele deve estar em umapartida a frio em sua nova célula e deve aplicar o processocorrespondente de registro.
Se uma mudança como essa não ocorrer, as listas devizinho serão enviadas com um período deNET_Neighbor_List_Max_Period.
Um tempo de randomização de + 20% deve ser adicionadoa estes períodos e tempos para se evitarem colisõesrepetitivas.
0 mestre de célula é o único ponto final que podeinicializar uma mensagem de difusão e ao mesmo tempo oúnico que não pode recebê-la. Deve indicar no cabeçalho deNET o número de hiperquadro (HFN) atual no momento dacriação.
Parte dos recursos vantajosos do presente assunto deprotocolo se refere a um mecanismo de roteamento de enlacedescendente. Em particular, a comunicação de enlacedescendente representa uma transmissão a partir da cabeçada rede para um único nó na rede de malha. Contudo, o pontoé descobrir um nó que pudesse estar em qualquer lugar, maso qual seja capaz de ser acessado no tempo mais curto.
O que vem a seguir se dirige mais particularmente auma funcionalidade de relê de célula em relação a umatabela de roteamento. Para a realização de uma comunicaçãode enlace descendente, o mestre de célula (ou relê) precisater recebido um primeiro número mínimo de listas de vizinhode modo a computar o melhor percurso para se alcançar odestino.
Como todo ponto final na célula é suposto como tendoenviado uma informação de seus melhores pais, o mestre decélula tem o conhecimento para alcançar qualquer pontofinal na célula. Ele apenas tem que dispor a informação queele recebe dentro de uma tabela de roteamento. Esta tabelade roteamento é atualizada a cada vez em que uma nova listade vizinho (ou mensagem de enlace interrompido; veja aseção dedicada) é recebida.
Devido ao fato de cada ponto final conhecer seus pais,o mestre de célula pode construir todos os caminhospossíveis entre qualquer ponto final e ele mesmo (isto defato é limitado pelo número de pais na lista de vizinho,mas provê caminhos possíveis suficientes sem sesobrecarregar o mestre de célula com dados demais a coletare processar). Os pais nas listas de vizinho são providos emordem, começando a partir do melhor. 0 melhor caminho podeser determinado ao se escolher o primeiro pai na listacomeçando a partir do destino final até o mestre de célula.
A tabela se moverá permanentemente; portanto, oalgoritmo precisa checar se em cada salto da criação, ocaminho não vai através do mesmo nó. Isto poderia levar,caso contrário, a um laço infinito ou a um percursocircular. Se o percurso atingiu esse caso, o algoritmodeverá ir de forma reversa no caminho e tentar os paisalternativos. Se nenhum caminho for encontrado, a camada deNET destruirá o pacote e reportará uma falha para a camadade API. Se houver um problema devido a um enlaceinterrompido ou um caminho circular, esta técnica nãogarantirá que o novo caminho encontrado seja o segundomelhor, mas assegurará que encontrará um caminho, se houver um.
A cada vez em que o mestre de célula receber uma listade vizinho atualizada, ele a usará para atualizar suatabela de roteamento. Deve ser notado que o mestre decélula apenas precisa substituir a entrada correspondentena tabela, sem recomputar coisa alguma.
Quando o mestre de célula precisa enviar uma mensagemde enlace descendente para um ponto final, ele seleciona omelhor caminho e menciona todas as etapas (endereços de nó)do caminho no cabeçalho de rede. Então, ele envia amensagem para o primeiro ponto final do caminho, e este aencaminhará para o segundo e assim por diante, até odestino final ser alcançado. Todo nó presente na tabela deroteamento pode ser selecionado para roteamento.
Finalmente, se nenhuma mensagem de um ponto finaltiver sido recebida por NET_Endpoint_TimeOut, o ponto finaldeverá ser apagado da tabela, bem como os caminhos atravésdele. A camada de API também pode requisitar a partir dacamada de NET a remoção de um nó especifico da tabela.
A presente Figura 5 7A é um exemplo de uma computaçãode caminho de enlace descendente para se alcançar o pontofinal 10. Os 3 melhores pais são mencionados nas listas devizinho. Algum ponto final que não tenha 3 pais coloca seusirmãos com caminhos alternativos. Os vizinhos de cada pontofinal são aqui classificados por seu SYNC_Merit. O caminhogerado é: 10«-8«-7<-2<- CM.
Uma mensagem de enlace descendente segue o caminhoindicado pelo mestre de célula, mas, devido ao possívelatraso entre a atualização de tabela de roteamento e estepacote de enlace descendente, a configuração de rede podeter 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 damensagem para o próximo destino, a camada de rede deveenviar de volta para o mestre de célula um enlaceinterrompido. Se, devido a uma limitação de hardware, nãohouver espaço na memória para a alocação do enlaceinterrompido no buffer de mensagem subindo, este deverá serdestruído.
Quando o enlace interrompido chega ao m camada deeletrodo, este deve atualizar sua tabela de roteamento pelaremoção do enlace. 0 enlace descendente então é reenviadose o caminho ainda existir. Este mecanismo de enlaceinterrompido não se aplica à confirmação de registro decé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 CRpara um roteamento de enlace descendente de exemplo. Quandoo número de entradas na tabela de roteamento muda agrupado,o mestre de célula atualiza seu indicador de tamanho decélula de acordo com a presente Figura 57C, e provê estainformação para a camada de MAC. A camada de MAC indicaráesta informação em seu cabeçalho e a propagará através dacélula. Quando a célula está cheia, isto é, quando o CSIassume seu valor máximo, nenhum ponto final pode requisitarse unir à célula.
Quando a tabela de roteamento atinge NET_Max_Nb_of_EPsentradas, a tabela e a célula são consideradas cheias.Neste caso, toda nova lista de vizinho que chegue ao mestrede célula deve ser usada para se encontrar um caminho parao envio de uma notificação de saída de célula de NET paraeste nó e, então, apagada. O nó que receber estanotificação de saída de célula de NET deve reconhecer opacote na camada de MAC e deixar a célula após um par deintervalos de tempo (para se garantir que o reconhecimentofoi recebido de forma bem sucedida).
A notificação de saída de célula de NET é um caso emparticular de uma mensagem de enlace descendente sem umacarga útil. Deve ser tratado como uma mensagem de enlacedescendente, exceto pelo fato de nenhuma mensagem de enlaceinterrompido dever ser enviada se um enlace forinterrompido no caminho. Isto é justificado pelo fato de omestre de célula ter destruído toda a informação relativa aeste ponto final e, portanto, não ser capaz de encontrar umcaminho alternativo. Note que a notificação de saída decélula de NET também pode ser usada pelo software degerenciamento superior para supressão do ponto finalselecionado em uma célula. A confirmação de registro decélula de NET também não deve disparar um enlaceinterrompido se a mensagem falhar em ser entregue. A razãopara isto é que o processo de registro de célula tem seupróprio mecanismo de nova tentativa o qual lida com essasfalhas. Quando o mestre de célula recebe uma notificação desaída de célula, ele deve remover o ponto finalcorrespondente de sua tabela de roteamento e atualizar seuindicador de tamanho de célula.
A tabela da presente Figura 57D resume as ações nacamada de NET de mestre de célula, quando a tabela deroteamento está cheia ou quando um nó não está na tabela deroteamento.
O que vem a seguir se refere mais particularmente a umtransporte de notificação de falta e à área funcional deregistro de célula de acordo com o presente assunto.Conforme é adicionalmente explicado em relação à seção decamada de MAC, um EP pode ouvir, no nível de MAC, que umvizinho experimenta uma falta de potência. Quando esteevento ocorre, a camada de MAC indica isso para a camada deNet, com a ID de falta e o tempo quando a mensagem foirecebida como parâmetros. Como uma conseqüência, a camadade Net deve construir uma mensagem de falta de Net, comtodos estes parâmetros (endereço de vizinho, ID de falta etempo de falta), e enviá-la para o relê de célula como umamensagem de enlace ascendente normal. Quando a mensagem defalta de NET atinge o relê de célula, a mensagem é dadapara a camada de API.
Quando um ponto final não é registrado em NET, acamada de API não pode enviar qualquer pacote. A RF LANdeve informar à camada de API quando o ponto final se tornaregistrado ou deixa de estar registrado (este último casoacontece quando o ponto final retorna para a fase dedescoberta ou comuta de célula) . Note que o mestre decélula sempre é considerado registrado em NET.
Uma vez que o ponto final seja registrado em NET, acamada de API está autorizada a se comunicar e pode começarseu próprio processo de registro.
Quando um ponto final comuta para uma outra célula, ascamadas de NET e de API precisarão se registrar junto aesta nova célula. A camada de NET informa primeiramente àcamada de API que ela não está mais registrada em umacélula e não pode enviar pacotes. 0 processo a seguir ésimilar à conexão a uma célula a partir da fase dedescoberta.
O protocolo Linknet será implementado em umaarquitetura que terá uma capacidade de armazenamentolimitada. Assim, há uma probabilidade não desprezível de amemória alocada para salvamento de mensagens, antes deserem enviadas, poder estar cheia. A cada vez em que acamada de API pede para enviar uma mensagem, a camada deNET confirma ou recusa a requisição. Isto significa que acamada de NET pode destruir o pacote a enviar e reportaruma falha para a camada de API. A camada de API então deveestar encarregada de postergar sua requisição e manter opacote em sua própria memória.
A camada de NET de mestre de célula também podereportar uma falha para a camada de API, se o caminho até odestino não puder ser computado ou se o destino não estiverna tabela de roteamento.Com respeito ao quadro de NET, deve ser entendido quea mensagem de rede é dividida em duas partes:
• O cabeçalho de rede contém toda a informaçãonecessária para roteamento da mensagem de rede apartir da fonte até o destino. Ele é dividido em duaspartes, as respectivas seções comum e dinâmica.
• O corpo de rede contém a mensagem a transferir para acamada de API.
A presente Figura 58 ilustra todos os campos que podemestar presentes no nivel de NET. O campo e as diferentesestruturas de mensagem são descritas em outro lugar aqui.
Na Seção Comum do cabeçalho de rede, há os aspectos aseguir, com a presente Figura 59 provendo uma tabela a qualapresenta várias facetas referentes ã informação de tipo dequadro 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 aspectosa seguir, alguns dos quais não aparecendo em toda mensagem(dai a natureza dinâmica desta seção de cabeçalho). Elessão descritos aqui em termos gerais, com outros detalhesdos vários tipos de mensagens discutidos aqui em outrolugar.
ORG, Remetente original:
O endereço do remetente original da mensagem.FID, ID de quadro:
O número de mensagem de rede dado pelo remetenteoriginal.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 seupróprio endereço do caminho.
RSD, Reservado:
Não usado no momento. Este campo deve ser reguladopara 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 propriedadesmencionadas.
BRK S, remetente de enlace interrompido:0 endereço de remetente da transmissão de enlaceinterrompido.
BRK D, destino de enlace interrompido:
O endereço de destino da transmissão de enlaceinterrompido.
HFN, número de hiperquadro:
0 campo de HFN se refere ao número de hiperquadro deMAC quando o mestre de célula inicializa a difusão.
DW FD, destino final:
O destino final para que a mensagem de enlacedescendente 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 enlacedescendente não recebida. Concerne à mensagem deenlace interrompido.
OID, ID de falta:
O número de falta do ponto final o qual experimentouuma falha de potência.OT, tempo de falta:
O tempo no qual o ponto final experimenta a falta depotência. É um formato de ITP.
Com referência adicional ao corpo de quadro e a umaPDU de aplicativo relacionada (APIPDU), ele contém umainformação relativa à camada de aplicativo. É a mensagemfinal que o protocolo entrega para a camada de aplicativo.Ela pode ser entregue para o ponto final de destino ou parao relê de célula.
O que vem a seguir se refere mais particularmente amensagens de NET. O comprimento de cabeçalho de NET parauma mensagem de enlace ascendente é de 8 bytes, conformerepresentado pela presente Figura 60. O pacote deacompanhamento (trace) é usado para fins de depuração deerro. Contudo, o comprimento de cabeçalho de NET para umcaminho de enlace descendente é de 5 bytes mais 4 bytesvezes o comprimento de caminho, conforme representado pelapresente Figura 61. Isto não inclui o próximo destino oqual é passado em um parâmetro a ser colocado no cabeçalhode MAC. O campo ORG não é incluído, uma vez que todas asmensagens de enlace descendente se originam no relê decélula. Adicionalmente, pela presente Figura 61, HOP-N é oendereço do destino final da mensagem de enlacedescendente, enquanto H0P-1 é o endereço do próximo destinoda mensagem de enlace descendente.Quando um ponto final quer enviar sua lista de vizinhopara o mestre de célula, ele a insere na localização docorpo de quadro. A requisição de registro de célula usa omesmo formato, mas com um tipo de quadro diferente.Conforme representado pela presente Figura 62, a lista devizinho ou o comprimento de requisição de registro decélula no nível de NET é de 21 bytes.
É uma combinação de uma mensagem de enlace ascendentee de uma mensagem de lista de vizinho. Conformerepresentado pela presente Figura 63, o comprimento decabeçalho de NET para um enlace ascendente com uma mensagemde lista de vizinho é de 21 bytes.
Conforme representado pela presente Figura 64, ocomprimento de cabeçalho de NET de difusão é de 4 bytes. 0campo de HFN se refere ao número de hiperquadro de MACquando o mestre de célula inicializa a difusão.
Quando o mestre de célula quer rejeitar um nó dacélula, ele envia uma notificação de saída de célula paraeste nó. 0 comprimento de mensagem é de 5 bytes mais 4bytes vezes o comprimento do caminho. Conforme representadopela presente Figura 65, a confirmação de registro decélula usa o mesmo pacote com um tipo de quadro diferentepara confirmação para um nó que ele é aceito na célula.
Se durante uma transmissão de enlace descendente umponto final não conseguir encaminhar a mensagem para opróximo ponto final, então, um enlace interrompido seráreportado. A mensagem de enlace interrompido consiste noendereço dos dois EPs definindo o enlace interrompido e namensagem original (a qual não foi armazenada no mestre decélula). Esta mensagem de enlace interrompido será usadapelo mestre de célula para a atualização de sua tabela deroteamento e para computação de um novo melhor caminho.Conforme representado pela presente Figura 66, ocomprimento de cabeçalho de NET da mensagem de enlaceinterrompido é de 18 bytes.
Se um EP ouvir uma mensagem de falta (em um nível deMAC) a partir de um EP o qual experimenta uma falta depotência, ele estampará no tempo a notificação de falta comseu tempo local usando um formato de ITP. Deve criar,então, uma mensagem de falta (NET) e enviá-la para o mestrede célula da mesma forma como uma mensagem de enlaceascendente. O OID é o mesmo que na mensagem de falta de MACoriginal. E o campo de OT é a estampa de tempo de ITP darecepção da notificação de falta (MAC). Conformerepresentado pela presente Figura 67, o comprimento decabeçalho de NET da mensagem de falta é de 11 bytes.
A notificação de saída de célula é enviada por umponto final imediatamente antes de deixar uma célula. Istoinforma ao mestre de célula que este ponto final pode serremovido da tabela de roteamento e o CSI ajustado de modoconforme. Como representado pela presente Figura 67, ocomprimento de NET de notificação de saída de célula é de 8bytes.
Com referência às interfaces e aos serviços de NET,será apreciado que a camada de Rede propõe uma variedade deserviços diferentes, conforme ilustrado em detalhesignificativo pelo assunto incluído na presente Figura 69.A camada de rede está encarregada do roteamento. A camadade rede conhece a vizinhança a 1 salto e pode tomar umadecisão quanto ao caminho a tomar para o encaminhamento deum pacote na direção de enlace ascendente ou de enlacedescendente. Se a mensagem tiver chegado ao seu destino, emum ponto final ou um relê de célula (mestre de célula), elaa proporcionará para a camada de API.
0 que vem a seguir se refere mais particularmente auma funcionalidade do presente assunto de protocolo comreferência às requisições de net.
Com um objetivo de enviar uma mensagem para umdestino, NET_Request_Send_Mono_Data, há o uso de argumentosde entrada: APIPDU, endereço de destino. A operação podeser descrita como a camada de API pedir à camada de NETpara enviar uma mensagem para o mestre de célula. Para omestre de célula: a camada de API pede à camada de NET paraenviar uma mensagem para um ponto final em particular.
Com um objetivo de enviar uma mensagem de difusão paraa célula inteira, até o relê de célula apenas,NET_Request_Send_Broadcast, há o uso dos argumentos deentrada requisitados: APIPDU. A operação pode ser descritacomo a camada de API requisitando que a camada de NET envieuma mensagem para a célula inteira.
Com um objetivo de enviar uma mensagem de RITP para acélula inteira, até o relê de célula apenas,NET_Request_Send_ITP, não há o uso de quaisquer argumentosde entrada. A operação pode ser descrita como a camada deAPI requisitando que a camada de NET envie uma mensagem deITP para a célula inteira. Esta requisição segue a mesmaabordagem que uma NET_Request_Send_Broadcast, exceto pelofato 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 entradarequisitados: estampa de tempo de ITP absoluta. A operaçãopode ser descrita como a camada de API requisitando que acamada de MAC atualize seu RITP com um novo valor de ITP.Esta requisição tem prioridade em relação a todas as outrasrequisições e é encaminhada diretamente para a camada deLLC.
Com um objetivo de medir o nível de interferênciamédio e sua função de autocorrelação no tempo,NET_Request_Environment_Analysis_Auto-Correlation, há o usode argumentos de entrada: Número de canal, Número deamostras. A operação pode ser descrita como uma requisiçãoque é encaminhada diretamente para a camada de LLC.
Com um objetivo de medir o nível de interferênciamédio em três canais especificados e sua função densidadede probabilidade, NET_Request_Environment_Analysis_PDF, háo uso dos argumentos de entrada requisitados: Números decanal (3), valor máximo de contador. A operação pode serdescrita como uma requisição que é encaminhada diretamentepara a camada de LLC.
Com um objetivo de proporcionar à camada de MAC ainformação quanto a se uma célula está autorizada ou não,NET_Request_Cell_Authorization, há o uso dos argumentos deentrada requisitados: Endereço de célula e Status decélula. A operação pode ser descrita como uma requisiçãoque é encaminhada diretamente para a camada de LLC.
Com um objetivo de proporcionar a remoção de um nó databela de roteamento, até o relê de célula (mestre decélula) apenas, NET_Request_Remove_Node, há o uso dosargumentos de entrada requisitados: Endereço de nó. Aoperação pode ser descrita como a camada de API poderinformar às camadas de Linknet que um nó não pertence maisà célula. A camada de NET assim removerá o nó da tabela deroteamento e atualizará o número de ponto final na célula.
Com um objetivo de enviar uma notificação de saída decélula para um nó, até o relê de célula (mestre de célula)apenas, NET_Request_Eject_Node, há o uso dos argumentos deentrada requisitados: Endereço de nó. A operação pode serdescrita como uma requisição que a camada de API poderequisitar à camada de NET para obter um nó fora da célula.A camada de NET então enviará uma notificação de saída decé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 comreferência a confirmações de NET.
Com um objetivo de responder aNET_Request_Send_Mono_Data, NET_Request_Send_Broadcast eNET_Request_Send_ITP, NETConfirmation_Send_Mono_Data,NET_Confirmation_Send_Broadcast e
NETConfirmation_Send_ITP, há o uso de argumentos de saídarequisitados: Status. A operação pode ser descrita como seproporcionar o status da requisição. Pode ser uma mensagemtransmitida, uma mensagem com falha ao ser transmitida,buffer cheio, caminho até o destino não encontrado ouquaisquer 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. Aoperação pode ser descrita como se proporcionar o status darequisição.
Com um objetivo de responder aNET_Reque s t_Environment_Analys i s_Auto-CorreIat ion,NET_Confirmation_Environment_Analysis_Auto-Correiation, háo uso de argumentos de saída requisitados: RSSI médio evalores de função de autocorrelação de RSSI. A operaçãopode ser descrita como um encaminhamento deLLC_Confirmation_Environment_Analysis_Auto-Correlation apartir da camada de LLC para a camada de API.
Com um objetivo de responder aNET_Request_Environment_Analysis_PDF,NET_Confirmation_Environment_Analysis_PDF, há o uso deargumentos de saída requisitados: valores de PDF de RSSIpara os três canais requisitados (3 χ 24 valores) . Aoperação pode ser descrita como um encaminhamento deLLC_Confirmation_Environment_Analysis_PDF a partir dacamada de LLC para a camada de API.
Com um objetivo de responder aNET_Request_Cell_Autorization,NET_Confirmation_Cell_Authorization, há o uso de argumentosde saída requisitados: Status. A operação pode serdescrita como um encaminhamento deLLC_Confirmation_Cell_Authorization a partir da camada deLLC para a camada de API.
Com um objetivo de responder aNET_Request_Remove_Node, até o relê de célula (mestre decélula) apenas, NET_Confirmation_Remove_Node, há o uso deargumentos de saída requisitados: Status. A operação podeser 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_Conf irmation_E ject_Node, há o uso de argumentos desaída requisitados: Status. A operação pode ser descritacomo se proporcionando o status da requisição.
0 que vem a seguir se refere mais particularmente àfuncionalidade do presente assunto de protocolo comreferência às Indicações de NET.
Com um objetivo de indicar para a camada de API queuma 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 umamensagem atinge seu destino final, a camada de NETproporcionar 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 ITPabsoluta. A operação pode ser descrita como umencaminhamento direto de LLC_Indication_ITP_Update a partirda camada de LLC para a camada de API. Esta indicação temprioridade em relação a todas as outras indicações.
Com um objetivo de indicar para a camada acima oestado de NET, NET_Indication_State, há o uso de argumentosde saída requisitados: Estado e Endereço de célula. Aoperação pode ser descrita como a camada de NET indicarpara a camada de API se o ponto final está sincronizado eregistrado junto a uma célula. Uma vez que esteja, a camadade API obtém os direitos de usar a rede.
Com um objetivo de indicar para a camada de API queuma notificação de falta foi recebida, até o relê de célulaapenas, NET_Indication_Outage_Received, há o uso deargumentos de saída requisitados: endereço de EP, ID defalta e tempo de falta. A operação pode ser descrita comoquando um relê de célula (ou mestre de célula) recebe umanotificação de falta através da RF LAN, ele deveproporcioná-la à camada de API. A camada de API sereportará ao agente de coleta usando o formato C12.22.
O que vem a seguir se refere a uma análise deestabilidade do algoritmo de compensação de deriva decristal e indica como computar os coeficientes de filtro.Para se discutir o comportamento do processo de correção dederiva, a presente Figura 70 prove um modelo diagramáticodo 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ãoda célula, conforme visto a partir do ponto final (isto é,conforme medido na própria referência de tempo do pontofinal). Qualquer discrepância entre a referência de tempode ponto final e a referência de tempo de célula resultaráem uma diferença entre TS_Length e TS_Length_Cell.
Considerando-se a reação de laço a uma mudança súbita emTS_Length_Cell, podem-se ajustar os coeficientes de filtropara se tornar esta resposta bem comportada.
Para fins analíticos, a presente Figura 71 é umasimplificação do diagrama da presente Figura 70. Para essasimplificação, o laço representado pode ser descrito pelasequações de recorrência a seguir:
<formula>formula see original document page 318</formula>Conforme será entendido por aqueles de conhecimentocomum 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 Tsiot:
<formula>formula see original document page 319</formula>
A expressão final para Tslot é:
<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 desegunda ordem. Para se olhar para o comportamento dinâmico,encontram-se os pólos desta função, escritos aqui na formapadrão:
<formula>formula see original document page 319</formula>
onde:
<formula>formula see original document page 319</formula>zeros de z2+bxz + b2 são ^^^^ Relações
simples entre Jb1, b2 e os pólos da função de transferênciasão representados por:
<formula>formula see original document page 320</formula>
Uma abordagem simples que economiza tempo paraavaliação dos coeficientes de filtro é mapear os pólos dafunção de transferência discreta no tempo para os pólos dafunção de transferência de tempo continua correspondente.
Estes pólos são dados por ^^^^ oncie z é ofator de amortecimento e CD0 é a freqüência angular dosistema de tempo contínuo equivalente. Estes pólos estãorelacionados aos pólos no plano z por z = esT, 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çãode transferência em termos dos parâmetros de sistema detempo 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 deamostras usadas para computação da média (realmente, é umfiltro de passa baixa e não uma média) . Isto é definidoarbitrariamente como o número de amostras necessárias parase 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 doscoeficientes de filtro em termos de Navg e do fator deamortecimento ζ:
<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 degraudesse laço em uma reação a uma mudança no comprimento deintervalo de tempo de célula de 100 ms para 110 ms. 0sistema atinge um valor estável após em torno de 20ressincronizações com um excesso esperado de 4,6%. O valorpadrão a seguir para os parâmetros de camada de MAC podemser 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çãoda rede de malha é um outro recurso vantajoso presenteregulado. Em uma rede de malha, um método é propostopresentemente para se computar o atraso de propagação entrequalquer nó na rede e o nó de raiz da rede. Este atraso depropagação então é usado como um critério para a seleção domelhor percurso dentre vários na rede.
A estabilidade e a performance da rede de malha sãocom base na sua capacidade de auto-otimizar e autocurar suatopologia. Esta auto-otimização da rede também éfundamental para o equilíbrio e a limitação do tráfego derede. Portanto, é importante prover o protocolo com um bomalgoritmo de seleção de percurso. O melhor percurso deveter as propriedades a seguir:
• O melhor percurso deve ter a latência mais curta dotransmissor para o receptor.
• O melhor percurso deve minimizar o número deretransmissões.
• O melhor percurso deve causar tão pouca interferênciaquanto possível.
O presente assunto é para usar o critério de "percursomais curto" é escolher o melhor percurso dentre vários. Opercurso mais curto é definido aqui como o percurso com oatraso de propagação médio mais curto. Uma referência éfeita aqui às ilustrações diagramáticas das presentesFiguras 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 outantas vezes quanto necessário para se tornar bem sucedidaa transmissão. Para fins práticos, o número de tentativasde retransmissões é limitado a algum valor máximo de modo ase evitar perder tempo em um enlace interrompido. 0 tempomédio gasto para a transmissão de uma mensagem a partir donó A para o nó B é chamado neste protocolo o atraso depropagação local (LPD) de A para B. É direto estender esteconceito para um percurso mais complexo. Por exemplo, oatraso de propagação entre os nós A e D ao longo dopercurso ABCD (veja a presente Figura 73A) é a soma dosatrasos 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ó, cadanó está ciente apenas de seus vizinhos imediatos e,portanto, não pode fazer diretamente a soma de todos osatrasos 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) eo atraso de propagação global (GPD). Um nó computará o LPDpara cada um de seus nós vizinhos na direção da raiz derede. 0 GPD de um nó é definido como o atraso de propagaçãototal mais curto do nó todo o caminho até o nó de raiz darede. Aqui, mais curto significa que há vários caminhospossíveis de um nó até o nó de raiz, e aquele com o atrasode propagação mais curto é selecionado e usado para adefinição do atraso de propagação global (GPD) do nó.
Como um exemplo, para a rede ilustrada na presenteFigura 73B, o GPD a partir de A até a raiz será:
GFD(A) - Min { [LFO(AyB) + LPD(B5D)Ji [LPD(AiC) + LPD(CiD)] }
Para se tornar a computação de GPD possível apenas como 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 presenteFigura 73C, o GPD de A até a raiz será computado destaforma:
GPD(A) - Min { [LPD(A1B) + GPD(B)J, [LPD(AjC) + GPD(C)] },
onde GPD (A) é o atraso de propagação total de A até araiz e GPD(B) é o atraso de propagação total de B até araiz.
As operações detalhadas a serem realizadas dentro deum nó, então, são:
• Cada nó mantém um registro de todas as tentativas decomunicação com cada um dos nós na direção da raiz darede e computa uma taxa de sucesso de comunicaçãoestatística com cada um destes nós.
• A partir desta taxa de sucesso de comunicação, umatraso de propagação local médio é computado para cadaenlace a um salto.
• A partir do GPD dos nós vizinhos, o nó computará oatraso de propagação total ao longo de cada caminhoaté o nó de raiz e selecionará o valor mais curto paraa definição de seu próprio valor de GPD.
O nó então tornará seu valor de GPD acessível a todonó em seu alcance pela atualização de seu cabeçalho demensagem.
Os detalhes matemáticos desse presente assunto podemser destacados conforme se segue. Nós consideraremos umenlace de salto único (ponto a ponto); em um ambiente semcolisã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 dotransmissor para o receptor.
Considerar o efeito de colisões sobre o atraso depropagação médio significa considerar todos os casospossíveis: nenhuma colisão ocorreu, uma colisão ocorreu,duas colisões, e assim por diante. O atraso de propagaçãoserá dado por:
<formula>formula see original document page 325</formula>
Aqui, P é a taxa de pacote de sucesso e Tr é o tempode espera entre retransmissões.
Para se manter a derivação adicional simples, pode-seassumir que este tempo é constante. A expressão pode serfatorada 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 depropagaçã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 valorde atraso de propagação médio preferencialmente deve seratualizado após cada uso de qualquer dado enlace. Aexpressão do atraso de propagação médio como uma função donúmero de utilização de enlace η é escrito conforme sesegue:
<formula>formula see original document page 325</formula>
Este atraso pode ser dividido em uma parte estática euma parte dinâmica:
<formula>formula see original document page 326</formula>
onde Dr (n) é a parte do atraso de propagação devido aretransmissões, normalizado para o tempo de espera deretransmissão. Dr (n) está diretamente relacionado à taxa desucesso de pacote por:
<formula>formula see original document page 326</formula>
Após cada tentativa de transmissão de pacote em umdado enlace, a taxa de sucesso de pacote P(n) é atualizadacom 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 acomputação da média e PS (n) é o sucesso / a falha natentativa η:
<formula>formula see original document page 326</formula>
A partir da equação de atualização de PSR, pode-sederivar uma equação para a atualização do atraso depropagaçã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çãode qualquer enlace então são:
<formula>formula see original document page 327</formula>
Se uma tentativa de transmissão falhar, nós usaremos aprimeira equação; se ela for bem sucedida, nós usaremos asegunda. Isto pode ser estendido facilmente para umpercurso de salto múltiplo da forma a seguir:
<formula>formula see original document page 327</formula>
onde a soma é estendida para todos os saltosindividuais de um percurso. Quando esta equação é usadapara fins de comparação de percursos diferentes, ela podeser normalizada da forma a seguir:
<formula>formula see original document page 327</formula>
Os benefícios principais incluem: leva a uma seleçãode percurso ótima; e pode ser implementado em cada nó comapenas o conhecimento local da vizinhança.
O que vem a seguir se refere ao presente assunto deprotocolo referente à operação para gerenciamento de cargade tráfego, particularmente incluindo cenários de respostaenvolvendo falhas de transmissão de pacote.
De modo a mais bem portar as presentes regras degerenciamento de tráfego, precisa-se fazer várias hipótesesde simplificação, porque o problema de colisões de RF éextremamente complexo. A questão em mãos não é a mesma quetentar fazer avaliações acuradas de carga de tráfego.
Algoritmos de gerenciamento de carga de tráfego detalhadossão estabelecidos na descrição de protocolo em outro lugaraqui.
Para se começar, podem-se analisar as possíveis causaspara uma falha de transmissão de pacote e a cura possívelcorrespondente para cada caso, assumindo, em uma primeiraetapa, que a causa da falha seja conhecida. Istoconsiderará a análise do problema de fluxo de tráfego norelê de célula e derivará uma regra de limitação de tráfegosimples a partir deste caso especial. Após isso, umaestratégia mais global pode ser destacada, para se lidarcom estas falhas através de tempos de espera eretransmissões adequados. Esta estratégia é projetada paraa otimização da latência e do ritmo de transferência deenlaces individuais entre nós. Não é projetada paracompartilhamento uniforme do tráfego entre diferentespercursos da rede em malha. O gerenciamento de cargaproposto impedirá a rede de entrar em colapso, se a demandaexceder ã capacidade da rede, mas não substituirá umgerenciamento no nível de aplicação. Espera-se que ogerenciamento de carga na camada de aplicativo disperse otráfego tão uniformemente quanto possível no tempo e eviterequisitar dados demais ao mesmo tempo. Uma sobrecarga derede de LAN deve permanecer uma situação excepcional.
A presente Figura 74 é uma tabela relativa a várioscenários de causas e soluções de falha de transmissão, pelopresente assunto de protocolo, os quais são adicionalmentecomentados aqui.
0 que vem a seguir é com referência em particular aoconjunto de condições de "Causa possível (1)" da Figura 74.
Um desvanecimento de Rayleigh é fortemente dependente dafreqüência. Como uma conseqüência, alguns canais terão umataxa de sucesso de pacote muito melhor do que outros. Istoserá particularmente notável com enlaces de longa distânciacom uma margem de enlace fraco. Não será incomum ver maisde 10 dB de diferença entre link budgets (tabelas quecontêm os dados referentes ao cálculo para análise deenlaces) 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 intencionalestiver presente. Um desvanecimento de Rayleigh é devido auma interferência de percurso múltiplo e as condiçõesambientais que tornam um canal ruim variarão no tempo e denó para nó. Portanto, não é simples excluir estes canaisruins da lista. Mais ainda, os regulamentos de rádio nosEstados Unidos impedem que se faça isso inteiramente; todosos canais devem ser usados da mesma forma. Quando um pacotefalha em ser reconhecido, devido a essas condições, asolução é tentar de novo em um outro canal. Não hánecessidade de esperar pela próxima tentativa detransmissão neste caso. Um tempo de espera adicional aquiapenas aumentaria a latência do sistema. Em alguns casosextremos, o sistema falhará em transmitir de forma bemsucedida seus pacotes em todos os canais disponíveis. Istopode ser causado por condições ambientais duras como umatempestade com raios ou pela presença de uma grandeobstrução próximo do ponto final. Esta condição também podevir de uma perda de sincronização. Neste caso, o pontofinal terá que introduzir um tempo de espera significativoe retomar suas transmissões mais tarde, conforme destacadona tabela da presente Figura 74.
0 que vem a seguir é com referência em particular aoconjunto 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 bandainterferirão com essas transmissões e alguns pacotes serãoperdidos devido a colisões. Obviamente, este fenômeno serámais importante para enlaces de longa distância devido auma margem de enlace mais fraca. Interferentes podem sertransmissores de potência baixa de banda estreita,saltadores de freqüência ou transmissores de banda larga depotência alta. A largura de banda de qualquer interferentenão obstante será pequena, se comparada com a largura debanda de ISM inteira e, na maioria dos casos, aretransmissão em um canal diferente será suficiente para seevitar a interferência. Como no caso prévio, não hánecessidade de esperar por uma tentativa de umaretransmissão. Um tempo de espera adicional aqui aumentariaa latência do sistema. Em alguns casos extremos, o sistemafalhará em transmitir de forma bem sucedida seus pacotespara todos os canais disponíveis. Isto pode ser causado porum interferente intencional de potência muito alta próximoo bastante do ponto final para deixar de detectar sua frontend de receptor. Neste caso, o ponto final terá queintroduzir um tempo de espera significativo e retomar suastransmissões mais tarde, conforme destacado na tabela dapresente Figura 74.
O que vem a seguir é com referência em particular aoconjunto de condições de "Causa possível (3)" da Figura 74.
Conforme o tráfego gerado pelo presente assunto deprotocolo crescer mais alto, colisões internas entrepacotes ocorrerão. Em algum ponto, estas colisões internasserão freqüentes o bastante para degradarem o ritmo detransferência efetivo do sistema. Neste caso, umatransmissão em um outro canal não melhorará a situação,porque todo ponto final segue o mesmo padrão de salto. Apartir de um ponto de vista de probabilidade de colisão, osistema se comporta como se apenas um canal fosse usado. Arelação entre probabilidade de colisão e ritmo detransferência efetivo é bem conhecida a partir da teoria deAloha com intervalo. A teoria clássica lida com o caso emque nenhum interferente intencional externo está presente.
Aqui, a situação é mais difícil de analisar, porque nóstemos ambos os tipos de colisões no mesmo tipo: colisõesinternas devido ao tráfego em questão e colisões externascom os outros usuários da banda. Daí, é desejávelintroduzir um mecanismo de regulagem para desaceleração dotráfego em questão, quando ele crescer acima de algumlimite, conforme destacado na tabela da presente Figura 74.
O que vem a seguir é com referência em particular aoconjunto de condições de "Causa possível (4)" da Figura 74.
Quando um ponto final não pode lidar com uma mensagementrando devido a limitações de memória, ele responderá comum reconhecimento negativo e descartará a mensagemrecebida. Isto também pode ser causado por umcongestionamento de tráfego em um nó remoto da rede. Quandoum nó precisa desacelerar seu tráfego, ele responderá comum reconhecimento negativo, quando seu buffer de entradaficar cheio. Esta condição se propagará etapa por etapa aolongo do percurso de tráfego a montante. 0 destinatário deum reconhecimento negativo deve tentear um outro destino ouretransmitir após algum tempo de espera, conforme destacadona tabela da presente Figura 74.
0 que vem a seguir prove uma discussão com referênciaa uma análise do fluxo de tráfego de transferência (viaupload) no relê de célula, de acordo com o presente assuntode protocolo. 0 relê de célula é o ponto em que todo otráfego converge. Se uma paralisação por congestionamentoocorrer, mais provavelmente ocorrerá no relê de célula;portanto, é importante analisar as condições de tráfegoneste caso especifico. Apenas a situação de transferência(via upload) é considerada aqui, porque este é o casorelevante para gerenciamento de carga de tráfego. Apresente Figura 75 representa de forma diagramática ummodelo 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, algumassimplificações são desejadas de modo a se caracterizaremmais prontamente algumas regras de gerenciamento detráfego. Uma hipótese é feita, por exemplo, que o relê decélula (ponto final A na presente Figura 75) apenas podeouvir as transmissões de pontos finais de nivel 2 (pontosfinais Bi na Figura 75). Isto é uma hipótese idealizada. Emuma implementação real, transmissões bem sucedidasesporádicas entre os pontos finais de nivel 3 e o relê decélula ocorrerão mais provavelmente. Uma hipótese também éfeita quando aos pontos finais de nível 2 estarem fora dealcance uns dos outros. Isto parece com uma situaçãoidealizada para pontos finais de nível 2, mas é um piorcaso do ponto de vista do relê de célula, porque um pontofinal de nível 2 não tem conhecimento do tráfego enviadopor seus vizinhos para o relê de célula neste caso. Umaoutra presente hipótese simplificadora é que dois pacotes,dois reconhecimentos ou um pacote e um reconhecimentochegando a um receptor no mesmo intervalo de tempo semprecolidirão e resultarão em nada ser recebido. Obviamente,isto é uma hipótese pessimista, mas apenas simulaçõesextensivas permitirão uma modelagem mais acurada doprocesso de colisão.
A notação a seguir é utilizada para a descrição dofluxo de tráfego:
• R(Χ,Y,Z) = número médio de pacotes enviados peloponto final X, pretendido para o ponto final Y e acimado limite de sensibilidade para o ponto final Z, porintervalo de tempo;
S(XiYiZ) = número médio de pacotes enviados peloponto final X, pretendido para o ponto final Y erecebidos de forma bem sucedida pelo ponto final Z,por intervalo de tempo;
• T(Χ,Υ,Z) = número médio de pacotes únicosenviados pelo ponto final X, pretendido para o pontofinal Y e recebidos de forma bem sucedida pelo pontofinal Z, por intervalo de tempo (isto é, sem pacotesduplicados);
• U(X,Y,Z) = número médio de reconhecimentosenviados pelo ponto final X, pretendido para o pontofinal Y e acima do limite de sensibilidade para oponto final Z, por intervalo de tempo;
• V(X,Y,Z) = número médio de reconhecimentosenviados pelo ponto final X, pretendido para o pontofinal Y e recebidos de forma bem sucedida pelo pontofinal Z, por intervalo de tempo.
A densidade de entrada de tráfego total vista pelorelê de célula é a soma das densidades de tráfego geradaspor todos os filhos do relê de célula (pontos finais Bi naFigura 75). O tráfego total se divide em pacotes de dados ereconhecimentos. 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 denível 2 ,B= {B1, B2, Bn). A soma se estende por todos
os filhos de A (os pontos finais de nível 2) . Osreconhecimentos enviados pelo ponto final Bi e que sepretende que sejam para os filhos de Bi são ouvidos por A edevem ser incluídos no tráfego total enviado por A. Estetrá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 finsde avaliação de probabilidade de colisão, estes dois tiposde tráfego serão tratados da mesma forma. 0 tráfego totalentão é R (Β, A, A) + U (B, C, A).O ritmo de transferência de pacote de dados no relê decélula é dado por:
<formula>formula see original document page 335</formula>
onde nós introduzimos a taxa de sucesso de pacote para atransmissão de um pacote a partir do ponto final Bi até oponto final A:
<formula>formula see original document page 335</formula>
O primeiro termo na expressão da PSR é a probabilidadede todos os outros pontos finais de nivel 2 estaremsilenciosos quando Bi transmitir seu pacote. Estaprobabilidade é dada pela distribuição de Poisson para um"evento zero". A expressão entre colchetes é o valor médiodo número de eventos em um único intervalo de tempo. Opróximo termo, PSRe(A), é a probabilidade de o pacote dedados ser recebido sem colisão com interf erentes fora dapresente rede em questão. Finalmente, Q(A) é aprobabilidade de o ponto final estar no estado de recepçãoquando o pacote chegar. Esta probabilidade é igual a ummenos a probabilidade de o ponto final A estar reconhecendoum pacote previamente recebido:
<formula>formula see original document page 335</formula>
O relê de célula reconhecerá cada pacote recebido, eisto provê uma relação entre o número de pacotes recebidosde forma bem sucedida por Aeo número de reconhecimentoschegando a Bi:
<formula>formula see original document page 335</formula>
O número de reconhecimentos recebidos de forma bem335/345
sucedida por Bi é dado por:
V (A, Bif Bi ) = U{A, Bi, Bi) ASR (Ai Bi)
= R(BiiAfA) PSR (BnA)ASR(AfB1)onde a taxa de sucesso de reconhecimento, ASR (A, Bi) éintroduzida. Esta taxa de sucesso de reconhecimento é dadapor:
ASR (A, Bi) = exp [-R (Sof (Bi), Bi..B1)-U (Sof (Bi)fSof1 (Bt)f Bi)] PSRionde é definido que Sof 2 (Bi) = Sof (Sof (Bi) ) .
A partir do ponto de vista de aplicativo, o tráfegorelevante é o número de pacotes recebidos pelo relê decélula após um apagamento dos pacotes em duplicata. Umpacote em duplicata é gerado quando o reconhecimento falhaem ser recebido pelo remetente do pacote. Este número depacotes únicos deve ser igual ao número de reconhecimentosrecebidos de forma bem sucedida pelos pontos finais denível 2, T (Bii A, A) =V (A, Bi( Bi) .
Segue-se uma relação entre T (Bi, A, A) e R (Bii A,A) :
T ( Bi, A, A) = R ( B1, Af A) PSR (Bi, A) ASR (Af Bi)
Nesta equação, PSR (Bi, A) ASR (A, Bi) é a taxa desucesso para a transmissão do pacote e a recepção doreconhecimento seguinte. Esta é a "taxa de sucesso depacote" que o ponto final Bi medirá quando tentar enviar
seu pacote para o relê de célula. A taxa total de recepçãode pacotes não duplicados é obtida pela soma da equaçãoprecedente:
Τ(Β,Α,Α) = ΣΗ bO A1 A)PSR(Bn A) ASR(AiBt)
ι=]O número de reconhecimentos enviados por A para Biestá relacionado à taxa de tráfego por:
De uma forma similar, os reconhecimentos recebidospelo relê de célula, mas pretendidos para os pontos finaisde 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áfegono relê de célula então é:
<formula>formula see original document page 337</formula>
Para se tornar o problema tratável, é necessário fazerhipóteses adicionais. Uma dessas hipóteses adicionais é queo número de filhos de A é grande. Neste caso, ascontribuições individuais de cada Bi para o tráfego total épequena, e a taxa de sucesso de pacote se tornaindependente de i, conforme se segue:
<formula>formula see original document page 337</formula>
Para simplificar a expressão para a taxa de sucesso dereconhecimento, nós notamos que uma implementação dopresente assunto de protocolo não resulta em um sistemaAloha puro. Quando um filho de um ponto final de nível 2ouve seu pai enviar um pacote, ele posterga sua própriatransmissão, para evitar interferir com o reconhecimentoque seu pai está esperando. A probabilidade de Bi receberno mesmo intervalo de tempo um reconhecimento de um de seusfilhos (pretendido para seu neto) e um reconhecimento de A337/345
também é muito menor do que previamente assumido. Istoocorreria apenas se, no intervalo de tempo prévio, Bitivesse enviado um pacote para Aeo filho de Bi tambémtivesse enviado um pacote para seu próprio filho. Éprovável que isto produza uma colisão. A taxa de sucesso dereconhecimento, portanto, será aproximada por:
ASR(AiB) = PSRe
onde nós assumimos ainda que a taxa de colisão externa sejaa mesma para todos os pontos finais.
A relação entre o ritmo de transferência e a densidadede tráfego de entrada no relê de célula é simplificadapara:
<formula>formula see original document page 338</formula>
A taxa de reconhecimento de nível 2 para nível 3 éaproximada da mesma forma:
<formula>formula see original document page 338</formula>
E a densidade de entrada de reconhecimento no relê decélula se torna:
<formula>formula see original document page 338</formula>
onde se usa a conservação do número de pacotes de nívelpara 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>
O lado esquerdo desta equação é uma função monotônicade T (Β, A, A) , o lado direito tem um valor máximo para R(B, A, A) = 1, e segue-se uma equação que pode serresolvida para se encontrar o valor máximo possível de T(B, 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, apresente Figura 76 ilustra de forma gráfica o ritmo detransferência de dados, T (B, A, A) e a PSR (comreconhecimento) versus a densidade de entrada de tráfego, R(B, A, A) para PSRe = 0,8, enquanto a presente Figura 75ilustra graficamente o ritmo de transferência de dados, T(B, A, A) versus PSRe. Em qualquer caso, qualquer que sejaa taxa de colisão externa, o ritmo de transferência máximosempre é obtido para R (B, A, A) = 1. Esse recursointeressante é usado para um gerenciamento de carga detráfego pelo presente assunto de protocolo.
Em contraste com a discussão precedente concernente auma análise do fluxo de tráfego de transferência (viaupload) no relê de célula, de acordo com o presente assuntode protocolo, o que vem a seguir se refere maisparticularmente a uma avaliação desse fluxo de tráfego detransferência (via upload).
De modo a se controlar apropriadamente a carga detráfego pelo presente assunto, um ponto final precisaavaliar a quantidade de tráfego indo através da rede. Apartir da teoria eletromagnética, é sabido que qualquerpercurso de transmissão de antena para antena é recíproco.Por simplicidade, pode-se fazer uma hipótese adicional queos enlaces são equilibrados, isto é, as potênciastransmitidas e as sensibilidades são as mesmas para todosos pontos finais. Pode-se dizer, então, que se o nó A forum pai para o nó Bi, todo pacote transmitido por A seráouvido por Bi, com exceção dos pacotes perdidos porcolisão, ou porque Bi não estava no modo de recepção nomomento correto. Isto provê a um nó Bi uma forma simplesaproximada de conhecer a quantidade de tráfego com que seupai está lidando no momento. 0 nó Bi precisa ouvir osreconhecimentos transmitidos pelo relê de célula. Osreconhecimentos proporcionarão informação suficiente para aavaliação da carga de tráfego.
Para cada pacote recebido, o relê de célula envia umreconhecimento. Portanto, é calculado que U (A, B, Bi) = S(B, A, A). A taxa de reconhecimentos recebidos de forma bemsucedida por Bi é dada por:
V(AaBtBl) = U(AtBiBi)ASX(AtBl)Q(Bt)onde Q(Bi) é incluído porque o ponto final Bi estámonitorando reconhecimentos pretendidos para outros pontosfinais e nem sempre está no estado de escuta, quando estesreconhecimentos chegarem.
É sabido que a densidade de entrada de tráfego é dadapor R(B, A, A) = S(B, A, A) / PSR (A, Β) . A relação entreR(B, A, A) e V (A, B, Bi) é:
<formula>formula see original document page 341</formula>
Quando se mede V (A, Β, B±), devem-se considerar todosos reconhecimentos (positivos ou negativos) enviados por Ae recebidos por Bi. Mas os reconhecimentos pretendidos paraBi não são levados em consideração nesta computação. Apenasos reconhecimentos endereçados a outros pontos finais sãoregistrados, porque a finalidade é avaliar o tráfego emquestão externo com que o ponto final A tem que lidar. V(A, B, Bi) pode ser medido contando-se todos osreconhecimentos recebidos ocorrendo em uma janela de tempomóvel. Se a taxa de sucesso de pacote for expressa emtermos 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 peloponto final A como uma função do atraso de propagação e dataxa de recepção de reconhecimentos. A equação a seguirindicará quão ocupado é o ponto final A:
<formula>formula see original document page 341</formula>O que vem a seguir se refere mais particularmente aalgoritmos de gerenciamento de tráfego pelo presenteassunto de protocolo. Quando a camada de LLC recebe apartir da camada de NET uma requisição para enviar umpacote, ou quando ela reprograma uma transmissão nãoreconhecida, ela computará o comprimento do tempo de espera(Tx_Wait), antes de a requisição para enviar serencaminhada para a camada de MAC. Este tempo de espera écomputado como uma função do número de repetição. Afinalidade dessa abordagem é evitar inundar a interface dear com um grande número de pacotes, quando as condições detransmissão forem difíceis.
Quando a camada de MAC recebe uma requisição paraenviar um pacote a partir da camada de LLC, o comprimentode janela de randomização (Tx_Window) é computado como umafunção da carga de tráfego, sua finalidade sendo evitarusar a interface de Aloha com intervalo acima de seu pontoótimo. A transmissão de um pacote sempre ocorrerá na janelade randomização, após o tempo de espera. Essa faceta dopresente assunto é ilustrada pela presente Figura 80, aqual representa graficamente o tempo de espera e a janelade randomização para a (re)transmissão de um pacote. Essetempo de espera preferencialmente é computado de acordo comuma lei de retorno após colisão exponencial binária,conforme explicado de outra forma aqui.
O que vem a seguir se dirige mais particularmente auma mitigação vantajosa de circunstâncias de colisão pelopresente assunto. Neste contexto, a recepção simultânea dedois ou mais pacotes é referida como uma colisão. Se ospacotes colidindo tiverem a mesma potência, ambos serãoperdidos. Se um pacote for recebido com uma potência maisalta (mais alta do que alguma relação de portador parainterferência) e se o pacote mais potente chegar primeiro,o pacote mais forte será recebido de forma bem sucedida e omais fraco será perdido. Um conjunto de condições como essee/ou eventos é representado pela presente Figura 79, istoé, que representa um episódio de colisão como esse, em queum pacote (designado como o pacote 1) é perdido.
Se um pacote mais fraco chegar primeiramente, doiscenários serão possíveis, dependendo do tipo de receptorusado na porção pertinente da implementação. Se o receptortiver funcionalidades relativamente mais limitadas, eletravará no preâmbulo do primeiro pacote, indo para umabusca de palavra de sincronização e, então, para uma fasede demodulação. Quando o pacote mais forte chega, oreceptor não está em um estado de busca de preâmbulo eperde a palavra de sincronização do pacote mais forte.Ambos os pacotes são perdidos. Um conjunto de condiçõese/ou de eventos como esse é representado pela presenteFigura 80, isto é, representando um episódio de colisão emque ambos os pacotes (designados como pacote 1 e pacote 2)são perdidos. Na situação em que o receptor calha de ser umdispositivo mais sofisticado, o receptor é capaz dedemodular um pacote e concorrentemente buscar um novopreâmbulo. Nesse caso, ele pode receber o pacote maisforte. 0 mais fraco (pacote 1), contudo, é perdido em todosos casos.
Para mitigação da probabilidade de colisão comqualquer tipo de receptor, pode ser útil pelo presenteassunto evitar usar o primeiro subintervalo de tempo parareconhecimentos. Essa abordagem preferida evitará adestruição de alguns pacotes por reconhecimentos maisfracos chegando imediatamente antes do pacote.
Embora o presente assunto tenha sido descrito emdetalhes com respeito a modalidades especificas do mesmo,será apreciado que aqueles versados na técnica, mediante aobtenção de um entendimento do precedente, podemprontamente produzir alterações em, variações de eequivalentes a essas modalidades. Assim sendo, o escopo dapresente exposição é a titulo de exemplo, ao invés de atítulo de limitação, e o assunto não impede a inclusãodessas modificações, variações e/ou adições ao presenteassunto, conforme seria prontamente evidente para alguém deconhecimento comum na técnica.
Além disso, a discussão variada aqui nos traz e/ou sebaseia em abreviações e acrônimos, tendo os significadospretendidos conforme estabelecido na Lista de Definições aseguir, a qual faz parte da presente exposição.
Lista de Definições
• 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 umainterface para redes de comunicação de dados. É oprotocolo de API recomendado para ser usado com oprotocolo 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 umponto final e o mestre de célula através de um vizinhoespecificado.
· 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 pontofinal e um mestre de célula (o EP_GPD mínimo para umponto final).
· IEEE - Institute of Electrical and ElectronicsEngineers
• ISM - Industrial, cientifico e médico
• ISO - International Standards Organization
• ITP - Protocolo de tempo Itron
· Linknet - O nome do protocolo descrito no presentedocumento.
• LLC - Camada de controle de enlace lógico.
• LPDU - PDU de LLC.
• LPD - PD local. Atraso de propagação entre dois EPsvizinhos.
• 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 desenvolvimentode Linknet.
• WAN - Rede de área local
• Zigbee - Protocolo de padrão do IEEE.
Claims (25)
1. Metodologia para a geração de uma seqüência pseudo-randômica para uso em uma rede de salto de freqüência desistema de medição avançada, caracterizada pelo fato decompreender:o estabelecimento de uma rede que inclui umainstalação central e uma pluralidade de dispositivosfinais, pelo menos alguns desses dispositivos finaiscompreendendo dispositivos de metrologia, e onde cadadispositivo final é associado a um de uma pluralidade decélulas, a cada célula sendo atribuído um identificador decélula único;a construção de uma seqüência de salto externa parauma dada célula usando-se o identificador de célula únicoda dada célula como uma semente;o uso dos elementos da seqüência de salto externa paraa seleção de uma seqüência de alto interna de N saltos,onde o inteiro N é o número de canais usados pela rede desalto de freqüência de sistema de medição avançado; eaplicação da seqüência selecionada como um padrão desalto de transceptor para um dispositivo final selecionadona dada célula.
2. Metodologia, de acordo com a reivindicação 1,caracterizada pelo fato de a construção da seqüência desalto externa compreender:a fragmentação do identificador de célula para umadada célula em uma pluralidade de partes; ea geração de uma seqüência começando com elementoscorrespondentes às partes selecionadas de uma pluralidadede partes do identificador de célula e a formação deelementos subseqüentes na seqüência pela adiçãorepetidamente de uma pluralidade de elementos de seqüênciaprévia em conjunto.
3. Metodologia, de acordo com a reivindicação 1,caracterizada pelo fato de a seqüência de salto externa(OHS) ser construída pela fragmentação do identificador decélula para uma dada célula em pelo menos duas partes epela combinação de pelo menos duas partes em uma seqüênciade Fibonacci de acordo com a relação a seguir: <formula>formula see original document page 348</formula> onde o inteiro M é o comprimento da seqüência de saltoexterna.
4. Metodologia, de acordo com a reivindicação 1,caracterizada pelo fato de a seqüência de salto externa(OHS) ser construída pela fragmentação do identificador decélula em pelo menos quatro partes e pela combinação depelo menos quatro partes em uma seqüência de Tetranacci deacordo com a relação a seguir: <formula>formula see original document page 348</formula> onde o inteiro M é o comprimento da seqüência de saltoexterna.
5. Metodologia, de acordo com a reivindicação 1,caracterizada pelo fato de a seqüência de salto interna sercalculada de forma interativa com conhecimento de um saltoprévio e um número de seqüência de salto.
6. Metodologia, de acordo com a reivindicação 1,caracterizada pelo fato de a seqüência de salto interna sergerada cora um campo de Galois de ordem p, onde ρ é umnúmero primo.
7. Metodologia, de acordo com a reivindicação 6,caracterizada pelo fato de a seqüência de salto interna deN saltos especifica selecionada ser selecionada a partir deuma pluralidade de k seqüências de salto internasdiferentes, e onde a k-ésima seqüência de salto interna(IHS) é gerada pelo k-ésimo elemento primitivo (a) e podeser expressa como:<formula>formula see original document page 349</formula>
8. Metodologia, de acordo com a reivindicação 1,caracterizada pelo fato de ainda compreender:a configuração da rede para comunicações bidirecionaisentre a instalação central e cada um da pluralidade dedispositivos finais; ea configuração de cada dispositivo final na dadacélula para operar um transceptor usando uma seqüênciagerada de acordo com a referida construção e usando etapas;onde todos os dispositivos finais na dada célula sãosincronizados uns com os outros.
9. Metodologia, de acordo com a reivindicação 1,caracterizada pelo fato de a referida rede de salto defreqüência de sistema de medição avançado opera de acordocom um protocolo aloha de intervalo.
10. Rede de salto de freqüência de sistema de mediçãoavançado, caracterizada pelo fato de compreender:uma instalação central; euma pluralidade de dispositivos finais, pelo menosalguns desses dispositivos finais compreendendodispositivos de medição, com a referida instalação centrale a referida pluralidade de dispositivos finais sendoconfigurados para comunicações bidirecionais entre eles, ecom cada dispositivo final sendo associado a uma de umapluralidade de células, cada uma tendo um identificador decélula único;onde cada dispositivo final em uma dada célula éconfigurado para comunicações sincronizadas com cada outrodispositivo final na dada célula;onde as comunicações dentre células adjacentes sãosubstancialmente isoladas; eonde comunicações efetuadas por um ou maisdispositivos finais em uma dada célula são efetuadasusando-se um padrão de salto formado a partir de umacombinação alojada de duas seqüências, incluindo umaseqüência interna gerada com uma aritmética de campo deGalois e uma seqüência externa gerada usando-se oidentificador de célula único para a cada célula como umasemente.
11. Rede de salto de freqüência de sistema de mediçãoavançado, de acordo com a reivindicação 10, caracterizadopelo fato de o padrão de salto ser formado, maisparticularmente, pelo uso dos elementos da seqüênciaexterna para a seleção de uma seqüência interna de N saltosespecífica, onde o inteiro N é o número de canais usadospela rede de salto de freqüência de sistema de mediçãoavançado.
12. Rede de salto de freqüência de sistema de mediçãoavançado, de acordo com a reivindicação 11, caracterizadopelo fato de a seqüência externa (OHS) ser formada pela:fragmentação do identificador de célula para a dadacélula em uma pluralidade de partes; egeração de uma seqüência começando com elementoscorrespondentes a respectivas partes selecionadas dapluralidade de partes do identificador de célula e formandoelementos subseqüentes na seqüência pela adiçãorepetidamente de uma pluralidade de elementos de seqüênciaprévios em conjunto.
13. Rede de salto de freqüência de sistema de mediçãoavançado, de acordo com a reivindicação 10, caracterizadopelo fato de a seqüência externa (OHS) ser construída pelafragmentação do identificador de célula para a dada célulaem pelo menos duas partes e pela combinação de pelo menosduas partes em uma seqüência de Fibonacci de acordo com arelação a seguir:<formula>formula see original document page 351</formula>onde o inteiro M é o comprimento da seqüência de saltoexterna.
14. Rede de salto de freqüência de sistema de mediçãoavançado, de acordo com a reivindicação 10, caracterizadopelo fato de a seqüência externa (OHS) ser construída pelafragmentação do identificador de célula em pelo menosquatro partes e pela combinação de pelo menos quatro partesem uma seqüência de Tetranacci de acordo com a relação aseguir: <formula>formula see original document page 352</formula> onde o inteiro M é o comprimento da seqüência de saltoexterna.
15. Rede de salto de freqüência de sistema de mediçãoavançado, de acordo com a reivindicação 10, caracterizadopelo fato de a seqüência interna ser calculada de formaiterativa com conhecimento de um salto prévio e um númerode seqüência de salto.
16. Rede de salto de freqüência de sistema de mediçãoavançado, de acordo com a reivindicação 11, caracterizadopelo fato de a seqüência de salto interna ser gerada com umcampo de Galois de ordem p, onde ρ é um número primo, epelo fato de a seqüência de salto interna de N saltosespecífica selecionada ser selecionada a partir de umapluralidade de k seqüências de salto internas diferentes, eonde a k-ésima seqüência de salto interna (IHS) é geradapelo k-ésimo elemento primitivo (a) e pode ser expressacomo:IHS(k) = {lak,alal-ar).
17. Rede de salto de freqüência de sistema de mediçãoavançado, de acordo com a reivindicação 12, caracterizadopelo fato de a seqüência interna (IHS) poder ser expressacomo: <formula>formula see original document page 352</formula> onde IHS (k, n) é o número de canal do enésimo saltoda k-ésima seqüência interna e ak é o elemento primitivo dak-ésima seqüência interna, e onde o padrão de salto podeser expresso como a combinação alojada a seguir dasseqüências internas e externas:{[///5-(OHS(O),0) JHS(OHS(O),l), - ·}7HS(OHS(O), N-\)],[/HS (OHS(I)i 0), IHS (OHS( I), l) ,--JHS (OHS(I)i N -1)],[JHS(OHS(M -1),0), !HS(OHS(M -1),\)> -JHS(OHS(M -1), N -1)]}
18. Dispositivo de metrologia para uso com uma rede desalto de freqüência de sistema de medição avançado, oreferido dispositivo de metrologia caracterizado por umisso único, o referido dispositivo de metrologiacaracterizado pelo fato de compreender:uma porção de metrologia configurada para a medição doconsumo de um bem de consumo de serviço de utilidadepública;uma porção de transmissor configurada para transmitiruma informação de consumo; euma porção de receptor configurada para receber umainformação a partir de outros dispositivos de rede;onde a referida porção de transmissor e a referidaporção de receptor são configuradas para se comunicaremusando um padrão de salto de freqüência formado a partir deuma combinação alojada de duas seqüências, incluindo umaseqüência de salto interna gerada com aritmética de campode Galois e uma seqüência de salto externa gerada usando-seo identificador único para o dispositivo de metrologia comouma semente.
19. Dispositivo de metrologia, de acordo com areivindicação 18, caracterizado pelo fato de o padrão desalto ser formado, mais particularmente, pelo uso doselementos da seqüência externa para a seleção de umaseqüência interna de N saltos específica, onde o inteiro Né o número de canais usados pela rede de salto defreqüência de sistema de medição avançado.
20. Dispositivo de metrologia, de acordo com areivindicação 19, caracterizado pelo fato de a seqüência desalto externa (OHS) ser formada pela:fragmentação do identificador de célula para a dadacélula em uma pluralidade de partes; egeração de uma seqüência começando com elementoscorrespondentes a respectivas partes selecionadas dapluralidade de partes do identificador único e formandoelementos subseqüentes na seqüência pela adiçãorepetidamente de uma pluralidade de elementos de seqüênciaprévios em conjunto.
21. Dispositivo de metrologia, de acordo com areivindicação 18, caracterizado pelo fato de a seqüência desalto externa (OHS) ser construída pela fragmentação doidentificador único em pelo menos duas partes e pelacombinação de pelo menos duas partes em uma seqüência deFibonacci de acordo com a relação a seguir:<formula>formula see original document page 354</formula>onde o inteiro M é o comprimento da seqüência de saltoexterna.
22. Dispositivo de metrologia, de acordo com areivindicação 18, caracterizado pelo fato de a seqüência desalto externa (OHS) ser construída pela fragmentação doidentificador único em pelo menos quatro partes e pelacombinação de pelo menos quatro partes em uma seqüência deTetranacci de acordo com a relação a seguir:OHS(n) = Cell Identifier(«), η = 0,15 2,3OHS(n) = OHS{n -1) + 0HS{n - 2) + OHS(n - 3) + 0HS(n - 4), η = 4, · · ·, M -1onde o inteiro M é o comprimento da seqüência de saltoexterna.
23. Dispositivo de metrologia, de acordo com areivindicação 18, caracterizado pelo fato de a seqüência desalto interna ser calculada de forma iterativa comconhecimento de um salto prévio e um número de seqüência desalto.
24. Dispositivo de metrologia, de acordo com areivindicação 19, caracterizado pelo fato de a seqüência desalto interna ser gerada com um campo de Galois de ordem p,onde ρ é um número primo, e pelo fato de a seqüência desalto interna de N saltos específica selecionada serselecionada a partir de uma pluralidade de k seqüências desalto internas diferentes, e onde a k-ésima seqüência desalto interna (IHS) é gerada pelo k-ésimo elementoprimitivo (a) e pode ser expressa como:
25. Dispositivo de metrologia, de acordo com areivindicação 19, caracterizado pelo fato de a seqüênciainterna (IHS) poder ser expressa como:IHS(k,n) = ank, k = 0,1,2,··· AT-1, w = 0,1,2,-W-I,onde IHS (k, η) é o número de canal do enésimo saltoda k-ésima seqüência interna e ak é o elemento primitivo dak-ésima seqüência de salto interna, e onde o padrão desalto pode ser expresso como a combinação alojada a seguirdas seqüências de salto internas e externas: <formula>formula see original document page 356</formula>
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US84505606P | 2006-09-15 | 2006-09-15 | |
| US60/845,056 | 2006-09-15 | ||
| US84599406P | 2006-09-20 | 2006-09-20 | |
| US60/845,994 | 2006-09-20 | ||
| PCT/US2007/020022 WO2008033514A2 (en) | 2006-09-15 | 2007-09-14 | Metering rf lan protocol and cell/node utilization and management |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0716887A2 true BRPI0716887A2 (pt) | 2011-05-10 |
Family
ID=39184383
Family Applications (14)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| 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ó |
| 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ó |
| 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ó |
| 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à |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
Family Applications Before (3)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| 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ó |
| 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ó |
| 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ó |
Family Applications After (10)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
| 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ó |
Country Status (7)
| Country | Link |
|---|---|
| US (26) | US7843834B2 (pt) |
| EP (14) | EP2213985B1 (pt) |
| AU (15) | AU2007294728B2 (pt) |
| BR (14) | BRPI0722403A2 (pt) |
| CA (7) | CA2941447C (pt) |
| MX (1) | MX2009002801A (pt) |
| WO (1) | WO2008033514A2 (pt) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11665030B2 (en) * | 2019-03-29 | 2023-05-30 | Denso Corporation | Relay device |
Families Citing this family (511)
| 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 |
| US20080074285A1 (en) * | 2006-08-31 | 2008-03-27 | Guthrie Kevin D | Interface between meter and application (IMA) |
| US8312103B2 (en) * | 2006-08-31 | 2012-11-13 | Itron, Inc. | Periodic balanced communication node and server assignment |
| US20080071930A1 (en) * | 2006-09-01 | 2008-03-20 | Holbrook Kenneth J | Native network transport |
| US8787210B2 (en) | 2006-09-15 | 2014-07-22 | Itron, Inc. | Firmware download with adaptive lost packet recovery |
| US9354083B2 (en) * | 2006-09-15 | 2016-05-31 | Itron, Inc. | Home area networking (HAN) with low power considerations for battery devices |
| US7843834B2 (en) * | 2006-09-15 | 2010-11-30 | Itron, Inc. | Use of minimal propagation delay path to optimize a mesh network |
| 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 |
| US8036330B2 (en) * | 2006-12-29 | 2011-10-11 | Samsung Electronics Co., Ltd. | System and method for frequency synchronization in a wireless non-hierarchical 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 |
| 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 |
| US8036247B2 (en) | 2007-01-05 | 2011-10-11 | Frank Paul R | System and method of synchronizing real time clock values in arbitrary distributed systems |
| 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 |
| CN101589577B (zh) * | 2007-02-13 | 2012-06-20 | Sk电信有限公司 | 在无线个域网（wpan）中使用信标表来分配信标时隙的方法和wpan装置 |
| 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 | 华为技术有限公司 | 跟踪时钟源的方法和装置 |
| EP2203911A4 (en) | 2007-10-25 | 2011-12-28 | Trilliant Networks Inc | GAS METER HAVING ULTRA-SENSITIVE MAGNETIC MATERIAL RECONFIGURED ON COUNTER DIAL AND METHOD OF USING COUNTER RECONFIGURATION |
| 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 |
| US20090136042A1 (en) * | 2007-11-25 | 2009-05-28 | Michel Veillette | Application layer authorization token and method |
| CA2705021A1 (en) * | 2007-11-25 | 2009-05-28 | Trilliant Networks, Inc. | Proxy use within a mesh 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 |
| EP2215550A1 (en) | 2007-11-25 | 2010-08-11 | Trilliant Networks, Inc. | Energy use control system and method |
| EP2215616B1 (en) * | 2007-11-25 | 2016-08-17 | Trilliant Networks, Inc. | Communication and message route optimization and messaging in a mesh network |
| 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 |
| CA2714026A1 (en) * | 2007-11-25 | 2009-05-28 | Trilliant Networks, Inc. | System and method for transmitting and receiving information on a neighborhood area network |
| 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 |
| US7636759B1 (en) * | 2008-09-29 | 2009-12-22 | Gene Fein | Rotating encryption in data forwarding storage |
| US7636761B1 (en) * | 2008-09-29 | 2009-12-22 | Gene Fein | Measurement in data forwarding storage |
| US8458285B2 (en) * | 2008-03-20 | 2013-06-04 | Post Dahl Co. Limited Liability Company | Redundant data forwarding storage |
| US8311063B2 (en) | 2008-03-28 | 2012-11-13 | Silver Spring Networks, Inc. | Updating routing and outage information in a communications network |
| WO2009124016A2 (en) * | 2008-04-01 | 2009-10-08 | M&Fc Holding, Llc | Universal software defined home gateway |
| US8386585B2 (en) * | 2008-04-25 | 2013-02-26 | Tajitshu Transfer Limited Liability Company | Real-time communications over data forwarding framework |
| US20090267792A1 (en) * | 2008-04-25 | 2009-10-29 | Henry Crichlow | Customer supported automatic meter reading method |
| WO2009135122A1 (en) * | 2008-05-01 | 2009-11-05 | 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 |
| 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 |
| 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 |
| US8825480B2 (en) * | 2008-06-05 | 2014-09-02 | Qualcomm Incorporated | Apparatus and method of obtaining non-speech data embedded in vocoder packet |
| 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 |
| 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 |
| JP5344543B2 (ja) * | 2008-06-11 | 2013-11-20 | 任天堂株式会社 | データ処理プログラムおよびデータ処理装置 |
| US8787330B2 (en) * | 2008-06-11 | 2014-07-22 | 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 |
| US8699377B2 (en) | 2008-09-04 | 2014-04-15 | Trilliant Networks, Inc. | System and method for implementing mesh network communications using a mesh network protocol |
| KR101271918B1 (ko) * | 2008-09-22 | 2013-06-05 | 한국전자통신연구원 | 무선 시스템에서 디바이스 디스커버리 운용 방법 및 그 장치 |
| WO2010033244A1 (en) * | 2008-09-22 | 2010-03-25 | Silver Spring Networks, Inc. | Transparent routing in a power line carrier network |
| US8478823B2 (en) | 2008-09-29 | 2013-07-02 | Tajitshu Transfer Limited Liability Company | Selective data forwarding storage |
| 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 |
| US8266288B2 (en) * | 2008-10-23 | 2012-09-11 | International Business Machines Corporation | Dynamic expiration of domain name service entries |
| CA2741843C (en) | 2008-10-27 | 2018-05-08 | Mueller International, Llc | Infrastructure monitoring system and method |
| 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 |
| PL2396932T3 (pl) * | 2009-02-13 | 2012-10-31 | Philips Lighting Holding Bv | Sposób komunikacji w sieci zawierającej bezbateryjne urządzenie ZigBee, sieć i urządzenie do tego |
| US20120019397A1 (en) * | 2009-02-20 | 2012-01-26 | Aclara Power-Line Systems, Inc. | Wireless broadband communications network for a utility |
| WO2010105038A1 (en) | 2009-03-11 | 2010-09-16 | Trilliant Networks, Inc. | Process, device and system for mapping transformers to meters 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 |
| US8838017B2 (en) * | 2009-03-31 | 2014-09-16 | Qualcomm Incorporated | Wideband jammer detector |
| 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 |
| CN102282899B (zh) * | 2009-04-24 | 2014-01-01 | 华为技术有限公司 | 产生参考信号的方法 |
| EP3703222A1 (en) | 2009-05-07 | 2020-09-02 | Dominion Energy, Inc. | 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 |
| US8855100B2 (en) * | 2009-06-16 | 2014-10-07 | Qualcomm Incorporated | System and method for supporting higher-layer protocol messaging in an in-band modem |
| US8743864B2 (en) * | 2009-06-16 | 2014-06-03 | 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 |
| US8548025B2 (en) * | 2009-09-30 | 2013-10-01 | Landis+Gyr Innovations, Inc. | Methods and systems for distributing broadcast messages on various networks |
| 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 |
| WO2011043818A2 (en) | 2009-10-09 | 2011-04-14 | Consert Inc. | Apparatus and method for controlling communications to and from utility service points |
| 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 |
| JP5429303B2 (ja) * | 2009-11-18 | 2014-02-26 | 日本電気株式会社 | 中継装置、中継方法及びコンピュータプログラム並びに通信システム |
| 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 |
| US8855102B2 (en) * | 2010-01-29 | 2014-10-07 | Elster Solutions, Llc | Wireless communications providing interoperability between devices capable of communicating at different data rates |
| MX2012008613A (es) * | 2010-01-29 | 2012-10-05 | Elster Solutions Llc | Lecturas de datos de alta prioridad para adquisicion de datos en tiempo real en red de malla inalambrica. |
| JP5456068B2 (ja) * | 2010-02-02 | 2014-03-26 | 京セラ株式会社 | 無線通信装置 |
| 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 |
| AU2011265675B2 (en) | 2010-06-16 | 2015-02-12 | Mueller International, Llc | Infrastructure monitoring devices, systems, and methods |
| JP5331763B2 (ja) * | 2010-08-20 | 2013-10-30 | パナソニック株式会社 | ネットワーク管理装置、基地局装置及びネットワーク管理方法 |
| CA2809034A1 (en) | 2010-08-27 | 2012-03-01 | Randy Frei | 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 | 電錶及其通訊中繼方法 |
| US9588218B2 (en) | 2010-09-30 | 2017-03-07 | Echo Ridge Llc | System and method for robust navigation and geolocation using measurements of opportunity |
| US10212687B2 (en) | 2010-09-30 | 2019-02-19 | 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 |
| 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 |
| CN103430488B (zh) | 2010-11-05 | 2018-06-22 | 马克·卡明斯 | 编排无线网络运营 |
| US10694402B2 (en) | 2010-11-05 | 2020-06-23 | Mark Cummings | Security orchestration and network immune system deployment framework |
| US8774050B2 (en) * | 2010-11-09 | 2014-07-08 | Cisco Technology, Inc. | Dynamic wake-up time adjustment based on designated paths through a computer network |
| EP2641137A2 (en) | 2010-11-15 | 2013-09-25 | Trilliant Holdings, Inc. | System and method for securely communicating across multiple networks using a single radio |
| RU2013128767A (ru) * | 2010-11-25 | 2014-12-27 | Конинклейке Филипс Электроникс Н.В. | Система и способ для оптимизации передачи данных на узлы беспроводной ячеистой сети |
| 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 |
| US9319894B2 (en) | 2011-01-25 | 2016-04-19 | Lg Electronics Inc. | Method for transmitting and receiving power outage report and device therefor |
| US8970394B2 (en) * | 2011-01-25 | 2015-03-03 | Trilliant Holdings Inc. | Aggregated real-time power outages/restoration reporting (RTPOR) in a secure mesh network |
| EP3429163B1 (en) | 2011-02-10 | 2020-08-19 | 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 |
| US10097456B2 (en) * | 2011-02-25 | 2018-10-09 | Nokia Technologies Oy | Method and an apparatus for a gateway |
| WO2012122310A1 (en) | 2011-03-08 | 2012-09-13 | Trilliant Networks, Inc. | System and method for managing load distribution across a power grid |
| KR101794058B1 (ko) * | 2011-03-08 | 2017-12-04 | 삼성전자주식회사 | 간섭 회피를 위한 무선 네트워크 채널 할당 방법 |
| WO2012127095A1 (en) * | 2011-03-18 | 2012-09-27 | Nokia Corporation | 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 |
| 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 |
| US8842712B2 (en) | 2011-03-24 | 2014-09-23 | Gregory C. Hancock | Methods and apparatuses for reception of frequency-hopping spread spectrum radio transmissions |
| 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 |
| 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 |
| 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 |
| 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 |
| US20140292538A1 (en) * | 2011-09-07 | 2014-10-02 | Viraj Kumar Pathi | Intelligent coupler device for utility meter and method for operating thereof |
| US9369886B2 (en) | 2011-09-09 | 2016-06-14 | Viavi Solutions Inc. | Methods and apparatus for implementing a self optimizing-organizing network manager |
| US8885564B2 (en) * | 2011-09-16 | 2014-11-11 | Institute For Information Industry | Mobile station, base station, communication system and abnormal power down reporting method thereof |
| US9001787B1 (en) | 2011-09-20 | 2015-04-07 | Trilliant Networks Inc. | System and method for implementing handover of a hybrid communications module |
| US9706012B2 (en) * | 2011-09-26 | 2017-07-11 | 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 |
| WO2013052692A2 (en) * | 2011-10-04 | 2013-04-11 | Advanergy, Inc. | Data server 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 |
| US8660134B2 (en) | 2011-10-27 | 2014-02-25 | Mueller International, Llc | Systems and methods for time-based hailing of radio frequency devices |
| US8855569B2 (en) * | 2011-10-27 | 2014-10-07 | Mueller International, Llc | Systems and methods for dynamic squelching in radio frequency devices |
| US8737378B2 (en) | 2011-10-31 | 2014-05-27 | Itron, Inc. | Synchronization of nodes in a network |
| US9007923B2 (en) | 2011-10-31 | 2015-04-14 | Itron, Inc. | Quick advertisement of a failure of a network cellular router |
| EP2587872B1 (en) * | 2011-10-31 | 2014-08-13 | Itron, Inc. | Synchronization of nodes in a network |
| 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 |
| US8995361B2 (en) | 2011-11-11 | 2015-03-31 | Itron, Inc. | Multi-channel, multi-modulation, multi-rate communication with a radio transceiver |
| US8493868B2 (en) | 2011-11-11 | 2013-07-23 | Viet-Hung NGUYEN | Traffic load management |
| ES2697511T3 (es) * | 2011-11-11 | 2019-01-24 | Itron Global Sarl | Encaminamiento de comunicaciones basándose en disponibilidad de nodo |
| US9014190B2 (en) | 2011-11-11 | 2015-04-21 | Itron, Inc. | Routing communications based on node availability |
| US9516615B2 (en) | 2011-11-18 | 2016-12-06 | Apple Inc. | Selection of synchronization stations in a peer-to-peer network environment |
| US9473574B2 (en) | 2011-11-18 | 2016-10-18 | Apple Inc. | Synchronization of devices 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 |
| CA2856377C (en) | 2011-11-22 | 2018-10-23 | Aclara Technologies Llc | 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 |
| US9921597B2 (en) * | 2011-12-09 | 2018-03-20 | Kyocera Corporation | Power control apparatus, power control system, and control method |
| 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 |
| WO2013102927A2 (en) * | 2011-12-13 | 2013-07-11 | Tata Consultancy Services Limited | Generic device attributes for sensing devices |
| US8755331B2 (en) * | 2011-12-13 | 2014-06-17 | International Business Machines Corporation | Determining a physical location of a wireless mobile device |
| US20130155934A1 (en) * | 2011-12-16 | 2013-06-20 | Itron, Inc. | Network with secondary control channel |
| US9419888B2 (en) * | 2011-12-22 | 2016-08-16 | Itron, Inc. | Cell router failure detection in a mesh network |
| US8930455B2 (en) * | 2011-12-22 | 2015-01-06 | Silver Spring Networks, Inc. | Power outage detection system for smart grid using finite state machines |
| 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 |
| US9231657B2 (en) * | 2012-01-13 | 2016-01-05 | Texas Instruments Incorporated | Adaptive sub-band algorithm for point-to-point communication in PLC networks |
| TWI571166B (zh) * | 2012-01-13 | 2017-02-11 | 蘋果公司 | 在點對點網路環境中同步站台之選擇 |
| 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 |
| JP2015513826A (ja) * | 2012-02-16 | 2015-05-14 | コーニンクレッカ フィリップス エヌ ヴェ | プロキシ装置を使用して無線ネットワーク内でプロキシテーブルを管理する方法 |
| EP2815541B1 (en) | 2012-02-17 | 2018-06-27 | Osama Tarraf | 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 |
| US9591525B2 (en) | 2012-05-03 | 2017-03-07 | Itron Global Sarl | Efficient device handover/migration in mesh networks |
| US8755385B2 (en) | 2012-05-03 | 2014-06-17 | Itron, Inc. | Authentication using DHCP services in mesh networks |
| US9674589B2 (en) * | 2012-05-04 | 2017-06-06 | Itron, Inc. | Coordinated collection of metering data |
| US9742644B2 (en) | 2012-05-04 | 2017-08-22 | Itron, Inc. | Verification of connection of meters to network |
| 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 |
| CN102740428B (zh) * | 2012-06-20 | 2015-04-15 | 华为技术有限公司 | 调控发射功率的方法及无线路由设备 |
| US9231658B2 (en) | 2012-06-20 | 2016-01-05 | Texas Instruments Incorporated | Coexistence primitives in power line communication networks |
| 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 |
| EP2704378B1 (en) | 2012-08-27 | 2016-07-20 | Itron, Inc. | Bandwidth Management in an Advanced Metering Infrastructure |
| US9088994B2 (en) | 2012-08-31 | 2015-07-21 | Fujitsu Limited | Method and system for last gasp device detection |
| US8867396B2 (en) * | 2012-08-31 | 2014-10-21 | Fujitsu Limtied | Method and system for last gasp device identification |
| 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 |
| EP2896133A4 (en) * | 2012-09-11 | 2016-07-27 | Univ Washington Ct Commerciali | RECEIVER, DEVICE AND METHOD FOR THE WIRELESS RECEIVING OF DATA FROM A CURRENT 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 |
| WO2014044415A1 (en) * | 2012-09-24 | 2014-03-27 | Nec Europe Ltd. | 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 |
| US9280507B2 (en) | 2012-10-22 | 2016-03-08 | Intel Corporation | High performance interconnect physical layer |
| US9479196B2 (en) | 2012-10-22 | 2016-10-25 | Intel Corporation | High performance interconnect link layer |
| CN104737147B (zh) * | 2012-10-22 | 2018-11-06 | 英特尔公司 | 高性能互连物理层 |
| 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 |
| US9635605B2 (en) | 2013-03-15 | 2017-04-25 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US9713013B2 (en) | 2013-03-15 | 2017-07-18 | Elwha Llc | Protocols for providing wireless communications connectivity maps |
| US9832628B2 (en) | 2012-12-31 | 2017-11-28 | Elwha, Llc | Cost-effective mobile connectivity protocols |
| US9781664B2 (en) | 2012-12-31 | 2017-10-03 | Elwha Llc | Cost-effective mobile connectivity protocols |
| US8965288B2 (en) | 2012-12-31 | 2015-02-24 | Elwha Llc | Cost-effective mobile connectivity protocols |
| US9876762B2 (en) | 2012-12-31 | 2018-01-23 | Elwha Llc | Cost-effective mobile connectivity protocols |
| US9980114B2 (en) | 2013-03-15 | 2018-05-22 | Elwha Llc | Systems and methods for communication management |
| US9451394B2 (en) | 2012-12-31 | 2016-09-20 | 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 |
| US9426680B2 (en) | 2013-02-25 | 2016-08-23 | Itron, Inc. | Real-time radio spectrum assessment engine |
| US9077487B2 (en) | 2013-02-25 | 2015-07-07 | Itron, Inc. | Radio to support channel plans of arbitrary width and/or spacing |
| US9252998B2 (en) * | 2013-02-25 | 2016-02-02 | Itron, Inc. | Radio to detect and compensate for frequency misalignment |
| US8958506B2 (en) | 2013-02-25 | 2015-02-17 | Itron, Inc. | FSK/MSK decoder |
| CN104023375B (zh) * | 2013-02-28 | 2017-06-23 | 株式会社理光 | 网络节点发现方法和装置 |
| CN105027173B (zh) | 2013-03-07 | 2019-03-01 | 富士通株式会社 | 数据收集方法、系统以及数据收集程序 |
| 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 |
| US9693214B2 (en) | 2013-03-15 | 2017-06-27 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US9843917B2 (en) | 2013-03-15 | 2017-12-12 | Elwha, Llc | Protocols for facilitating charge-authorized connectivity in wireless communications |
| US9706382B2 (en) | 2013-03-15 | 2017-07-11 | Elwha Llc | Protocols for allocating communication services cost 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 |
| 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 |
| 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 |
| US9706060B2 (en) | 2013-03-15 | 2017-07-11 | 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 |
| 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 |
| US9847639B2 (en) | 2013-03-15 | 2017-12-19 | Dominion Energy, Inc. | Electric power system control with measurement of energy demand and energy efficiency |
| US10788401B2 (en) | 2013-03-15 | 2020-09-29 | Fluke Corporation | Remote sharing of measurement data |
| US9807582B2 (en) | 2013-03-15 | 2017-10-31 | Elwha Llc | Protocols for facilitating broader access in wireless communications |
| US9781554B2 (en) | 2013-03-15 | 2017-10-03 | Elwha Llc | Protocols for facilitating third party authorization for a rooted communication device in wireless communications |
| US9813887B2 (en) | 2013-03-15 | 2017-11-07 | Elwha Llc | Protocols for facilitating broader access in wireless communications responsive to charge authorization statuses |
| 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 |
| EP3448082B1 (en) * | 2013-03-29 | 2021-09-08 | VID SCALE, Inc. | Early packet loss detection and feedback |
| US9240934B2 (en) * | 2013-05-03 | 2016-01-19 | Landis+Gyr Innovations, Inc. | Monitoring the health of a home area network |
| KR20180095122A (ko) | 2013-06-12 | 2018-08-24 | 콘비다 와이어리스, 엘엘씨 | 근접성 서비스들을 위한 콘텍스트 및 전력 제어 정보 관리 |
| US10230790B2 (en) * | 2013-06-21 | 2019-03-12 | Convida Wireless, Llc | Context management |
| 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 |
| US20150130637A1 (en) * | 2013-11-11 | 2015-05-14 | Trackblue, Llc | Wireless Moisture Sensing Device, System, and Related Methods |
| US9904885B2 (en) | 2014-04-06 | 2018-02-27 | Vypin, LLC | Wireless medication compliance sensing device, system, and related methods |
| US10121028B2 (en) | 2013-06-26 | 2018-11-06 | Vypin, LLC | Asset tag apparatus and related methods |
| CN105431712B (zh) * | 2013-06-28 | 2018-10-09 | 飞利浦灯具控股公司 | 数据记录设备 |
| DK2822290T3 (da) * | 2013-07-03 | 2019-06-11 | Kamstrup As | Måleapparatnetværksnoder med beacon-signal omfattende signaldata |
| US10382059B2 (en) * | 2013-07-03 | 2019-08-13 | Samsung Electronics Co., Ltd. | Transmitting apparatus, encoding method thereof, receiving apparatus, and decoding method thereof |
| KR101975365B1 (ko) | 2013-07-10 | 2019-05-07 | 콘비다 와이어리스, 엘엘씨 | 상황 인식 근접 서비스들 |
| 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 |
| 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 |
| US9088983B2 (en) * | 2013-08-06 | 2015-07-21 | Cisco Technology, Inc. | Interleaving low transmission power and medium transmission power channels 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 | 上海诺基亚贝尔股份有限公司 | 用于设备到设备通信中的发现检测的方法和设备 |
| US9740875B2 (en) | 2013-09-30 | 2017-08-22 | Elwha Llc | Mobile device sharing facilitation methods and systems featuring exclusive data presentation |
| US9813891B2 (en) | 2013-09-30 | 2017-11-07 | Elwha Llc | Mobile device sharing facilitation methods and systems featuring a subset-specific source identification |
| 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 |
| US9774728B2 (en) | 2013-09-30 | 2017-09-26 | Elwha Llc | Mobile device sharing facilitation methods and systems in a context of plural communication records |
| US9838536B2 (en) | 2013-09-30 | 2017-12-05 | Elwha, Llc | Mobile device sharing facilitation methods and systems |
| US9826439B2 (en) | 2013-09-30 | 2017-11-21 | Elwha Llc | Mobile device sharing facilitation methods and systems operable in network equipment |
| 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 |
| US10571493B2 (en) | 2014-02-25 | 2020-02-25 | Itron, Inc. | Smart grid topology estimator |
| US11079417B2 (en) | 2014-02-25 | 2021-08-03 | Itron, Inc. | Detection of electric power diversion |
| 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 |
| EP3132647B1 (en) | 2014-04-16 | 2018-06-13 | Philips Lighting 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 |
| US10409920B1 (en) * | 2014-05-23 | 2019-09-10 | EMC IP Holding Company LLC | Data services for tiered memory |
| US10142847B2 (en) | 2014-05-23 | 2018-11-27 | Qualcomm Incorporated | Secure relay of discovery information in wireless networks |
| 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 |
| US10142444B2 (en) | 2014-07-01 | 2018-11-27 | Trinity Mobile Networks, Inc. | Methods, devices, and systems for implementing centralized hybrid wireless self-organizing networks |
| JP6544717B2 (ja) * | 2014-07-01 | 2019-07-17 | パナソニックＩｐマネジメント株式会社 | 電動工具システム |
| US9860730B2 (en) * | 2014-07-16 | 2018-01-02 | Itron, Inc. | Network discovery by battery powered devices |
| US10045291B2 (en) | 2014-07-16 | 2018-08-07 | Itron Global Sarl | Relay functionality of battery powered devices |
| US9614770B2 (en) * | 2014-07-21 | 2017-04-04 | Cisco Technology, Inc. | Network traffic control during limited power situations |
| US9843682B2 (en) * | 2014-07-21 | 2017-12-12 | Motorola Solutions, Inc. | Method and apparatus for subgroup call to group members missing a group call |
| EP3562249B1 (en) * | 2014-08-15 | 2024-07-24 | InterDigital Patent Holdings, Inc. | Supporting random access and paging procedures for reduced capability wtrus in an lte system |
| US9565620B2 (en) * | 2014-09-02 | 2017-02-07 | Mueller International, Llc | Dynamic routing in a mesh network |
| JP6498753B2 (ja) * | 2014-09-10 | 2019-04-10 | 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． | データ送信リンク確立装置及び方法、並びに通信システム |
| 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 |
| EP3216289B1 (en) * | 2014-11-07 | 2020-08-05 | Nokia Solutions and Networks Oy | Transmission of discovery reference signals on unlicensed carrier in a wireless network |
| 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 |
| WO2016127048A1 (en) * | 2015-02-06 | 2016-08-11 | David Akopian | 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 |
| 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 | 三菱電機株式会社 | 無線機、中継機、通信システムおよび識別子割当方法 |
| WO2017007949A1 (en) * | 2015-07-07 | 2017-01-12 | 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? |
| EP3375227B1 (en) * | 2015-11-12 | 2020-02-12 | 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 |
| EP3405109A4 (en) | 2016-01-20 | 2020-05-06 | 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 |
| 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 |
| US10788515B2 (en) | 2016-12-21 | 2020-09-29 | Itron, Inc. | Multi-piece current shunt with conductive channel for uniform current flow |
| 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 | 沖電気工業株式会社 | 同期システム、通信装置、同期プログラム及び同期方法 |
| US10849086B2 (en) | 2017-07-20 | 2020-11-24 | Itron Networked Solutions, Inc. | Compensating for oscillator drift in wireless mesh networks |
| US10433197B2 (en) | 2017-07-20 | 2019-10-01 | 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 |
| DE102017009564B4 (de) | 2017-07-20 | 2019-06-06 | Diehl Metering Systems Gmbh | Verfahren zum Verteilen von Daten |
| 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手机上行信号侦测系统 |
| RU2735232C1 (ru) * | 2017-10-27 | 2020-10-29 | Телефонактиеболагет Лм Эрикссон (Пабл) | Способ и устройство для обновления количества повторных передач в беспроводной ячеистой сети |
| 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 |
| CN110166268B (zh) * | 2018-02-13 | 2021-04-06 | 电信科学技术研究院有限公司 | 一种无线回程网络的通信方法及装置 |
| 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 |
| WO2019209816A1 (en) | 2018-04-24 | 2019-10-31 | Carrier Corporation | Automated routing in a mesh network of wireless messaging devices |
| WO2019209851A1 (en) | 2018-04-24 | 2019-10-31 | Carrier Corporation | Automated 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 |
| US11178530B2 (en) * | 2018-07-13 | 2021-11-16 | Itron, Inc. | Power-efficient discovery process for nodes within a wireless mesh network |
| US10911929B2 (en) | 2018-07-13 | 2021-02-02 | 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 |
| JP7331086B2 (ja) | 2018-08-27 | 2023-08-22 | シグニファイ ホールディング ビー ヴィ | Ｒｆベースの存在／位置検出のためのネットワークノードの適合性の判断 |
| JP7150882B2 (ja) | 2018-08-27 | 2022-10-11 | グーグル エルエルシー | メッシュネットワークにおける同期受信 |
| 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 |
| WO2020164757A1 (en) * | 2019-02-15 | 2020-08-20 | Signify Holding B.V. | Determining a network route which avoids nodes with a rf-based presence and/or location detection function |
| CN109831828A (zh) * | 2019-03-25 | 2019-05-31 | 宁夏隆基宁光仪表股份有限公司 | 一种网络拓扑结构的lora组网方法、装置及存储介质 |
| 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 |
| IT202000000490A1 (it) * | 2020-01-13 | 2021-07-13 | Pietro Fiorentini Spa | Apparecchio per la misurazione di un fluido. |
| US11682094B2 (en) | 2020-01-13 | 2023-06-20 | Florida Power & Light Company | Public reporting of power line-down conditions |
| 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 |
| US11328357B2 (en) | 2020-08-07 | 2022-05-10 | Hyannis Port Research, Inc. | Sequencer bypass with transactional preprocessing in distributed system |
| 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 |
| 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 |
| US11088959B1 (en) | 2020-08-07 | 2021-08-10 | Hyannis Port Research, Inc. | Highly deterministic latency in a distributed system |
| 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 |
| 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 | 利尔达科技集团股份有限公司 | 一种基于分时间片竞争上报的集抄方法 |
| US11979924B2 (en) * | 2021-02-25 | 2024-05-07 | Charter Communications Operating, Llc | Device address bundling for IoT communication |
| WO2022194331A1 (en) | 2021-03-15 | 2022-09-22 | 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 |
| CA3219476A1 (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 |
| 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 |
| US11483224B1 (en) * | 2021-08-13 | 2022-10-25 | Itron, Inc. | Determining network reliability using message success rates |
| US11924077B2 (en) * | 2021-08-13 | 2024-03-05 | Itron, Inc. | Determining network reliability using message success rates |
| US12068931B2 (en) | 2021-08-13 | 2024-08-20 | Itron, Inc. | Determining network reliability using message success rates |
| CN113676980B (zh) * | 2021-08-13 | 2024-05-03 | 上海庆科信息技术有限公司 | 一种中继节点确定方法、装置、设备及可读存储介质 |
| US12047264B2 (en) | 2021-08-13 | 2024-07-23 | Itron, Inc. | Determining network reliability using message success rates |
| CN114007243A (zh) * | 2021-10-29 | 2022-02-01 | 重庆邮电大学 | 一种宽带微功率网络性能在线分析系统与方法 |
| US20230246954A1 (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 |
|---|---|---|---|---|
| US52328A (en) * | 1866-01-30 | Improved mode of attaching car-wheels to axles | ||
| US129005A (en) * | 1872-07-16 | Improvement in portable steam-engines | ||
| US201397A (en) * | 1878-03-19 | Improvement in steam-engines for cotton-presses | ||
| US24235A (en) * | 1859-05-31 | jl alexander e | ||
| US38548A (en) * | 1863-05-19 | Improvement in railroad-rails | ||
| US163144A (en) * | 1875-05-11 | Improvement in ice-machines | ||
| US226179A (en) * | 1880-04-06 | Wagon-seat | ||
| US62224A (en) * | 1867-02-19 | B rawsof | ||
| US61623A (en) * | 1867-01-29 | William c | ||
| US43860A (en) * | 1864-08-16 | Improvement in the manufacture of paper | ||
| US278440A (en) * | 1883-05-29 | leland | ||
| US85928A (en) * | 1869-01-19 | Improvement in fen-holders | ||
| US271006A (en) * | 1883-01-23 | James a | ||
| US12935A (en) * | 1855-05-22 | Francis s | ||
| US4555A (en) * | 1846-05-30 | Botary steam-engine | ||
| US218616A (en) * | 1879-08-19 | Improvement in fire-backs | ||
| US179149A (en) * | 1876-06-27 | Improvement in seeding-machines | ||
| US548526A (en) * | 1895-10-22 | Valve releasing gear | ||
| US52290A (en) * | 1866-01-30 | Improvement in artificial teeth | ||
| US19725A (en) * | 1858-03-23 | Improvement irj plows | ||
| US53639A (en) * | 1866-04-03 | Improved car-coupling | ||
| US171696A (en) * | 1876-01-04 | Improvement in gage-lathes | ||
| US48199A (en) * | 1865-06-13 | Machine for printing paper-hangings | ||
| US78029A (en) * | 1868-05-19 | James t | ||
| US43961A (en) * | 1864-08-30 | Improvement in fliers for spinning-frames | ||
| US43059A (en) * | 1864-06-07 | Improvement in spindle-bolsters for spinning-machines | ||
| US63723A (en) * | 1867-04-09 | hudson | ||
| US74015A (en) * | 1868-02-04 | District of | ||
| US146985A (en) * | 1874-02-03 | Improvement in compositions for cornices | ||
| US172024A (en) * | 1876-01-11 | Improvement in lawn-sprinklers | ||
| US93484A (en) * | 1869-08-10 | Improved carriage-jack | ||
| US147097A (en) * | 1874-02-03 | Improvement in machines for gluing moldings | ||
| US88083A (en) * | 1869-03-23 | Improvement in blast, smelting, and cupola furnaces | ||
| US218873A (en) * | 1879-08-26 | Improvement in electric telephones | ||
| US192415A (en) * | 1877-06-26 | Improvement in apparatus for loading and unloading wagons | ||
| US243867A (en) * | 1881-07-05 | Elihtj dodds | ||
| US190055A (en) * | 1877-04-24 | Improvement in the manufacture of shovel-blanks | ||
| US103486A (en) * | 1870-05-24 | Improved clothes-drier | ||
| US8663A (en) * | 1852-01-13 | Turning prisms | ||
| 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 |
| EP0318816A3 (de) * | 1987-11-28 | 1990-06-13 | Hermann Hemscheidt Maschinenfabrik GmbH & Co. | Hydraulischer Stoss- und Schwingungsdämpfer mit regelbarer Dämpfung |
| 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 |
| 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 |
| US4977577A (en) | 1988-11-02 | 1990-12-11 | 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 |
| US5119396A (en) | 1990-08-27 | 1992-06-02 | Axonn Corporation | Binary phase shift keying modulation system |
| USRE35829E (en) | 1990-08-27 | 1998-06-23 | Axonn Corporation | Binary phase shift keying modulation system and/or frequency multiplier |
| US5198796A (en) | 1991-06-27 | 1993-03-30 | Distribution Control Systems, Inc. | Outbound signal detector system and method |
| US5377232A (en) | 1992-01-09 | 1994-12-27 | Cellnet Data Systems, Inc. | Frequency synchronized bidirectional radio system |
| US5604768A (en) | 1992-01-09 | 1997-02-18 | 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 |
| 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 |
| WO1994028663A1 (en) | 1992-05-08 | 1994-12-08 | Axonn Corporation | A 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 |
| US7054271B2 (en) | 1996-12-06 | 2006-05-30 | Ipco, Llc | Wireless network system and method for providing same |
| US6044062A (en) | 1996-12-06 | 2000-03-28 | Communique, 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 |
| 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) |
| US6430268B1 (en) | 1997-09-20 | 2002-08-06 | Statsignal Systems, Inc. | Systems for requesting service of a vending machine |
| US6628764B1 (en) | 1997-02-14 | 2003-09-30 | Statsignal Systems, Inc. | System for requesting service of a vending machine |
| 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) |
| 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 |
| 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 |
| US6263009B1 (en) | 1997-06-23 | 2001-07-17 | Cellnet Data Systems, Inc. | Acquiring a spread spectrum signal |
| US6456644B1 (en) | 1997-06-23 | 2002-09-24 | Cellnet Data Systems, Inc. | Bandpass correlation of a spread spectrum signal |
| US6178197B1 (en) | 1997-06-23 | 2001-01-23 | Cellnet Data Systems, Inc. | Frequency discrimination in a spread spectrum signal processing system |
| US6047016A (en) | 1997-06-23 | 2000-04-04 | Cellnet Data Systems, Inc. | Processing a spread spectrum signal in a frequency adjustable system |
| 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 |
| CA2309926A1 (en) | 1997-11-14 | 1999-05-27 | Erik Muench | Method for maintaining the synchronized execution in fault resilient/fault tolerant computer systems |
| 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 |
| US6028522A (en) | 1998-10-14 | 2000-02-22 | Statsignal Systems, Inc. | System for monitoring the light level around an ATM |
| US6914533B2 (en) | 1998-06-22 | 2005-07-05 | Statsignal Ipc Llc | System and method for accessing residential monitoring 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 |
| US6437692B1 (en) | 1998-06-22 | 2002-08-20 | Statsignal Systems, Inc. | System and method for monitoring and controlling remote devices |
| US6914893B2 (en) | 1998-06-22 | 2005-07-05 | Statsignal Ipc, Llc | System and method for monitoring and controlling remote devices |
| 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 |
| WO2000019174A1 (en) | 1998-09-29 | 2000-04-06 | 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 |
| 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 |
| US6232885B1 (en) | 1998-10-15 | 2001-05-15 | Schlumberger Resource Management Services, Inc. | Electricity meter |
| US6700902B1 (en) | 1998-10-19 | 2004-03-02 | Elster Electricity, Llc | Method and system for improving wireless data packet delivery |
| US6424270B1 (en) | 1998-10-30 | 2002-07-23 | Schlumberger Resource Management Services, Inc. | Utility meter interface unit |
| US6502135B1 (en) * | 1998-10-30 | 2002-12-31 | Science Applications International Corporation | Agile network protocol for secure communications with assured system availability |
| US6839759B2 (en) * | 1998-10-30 | 2005-01-04 | Science Applications International Corp. | Method for establishing secure communication link between computers of virtual private network without user entering any cryptographic information |
| CA2723504C (en) * | 1998-10-30 | 2014-04-29 | Virnetx, Inc. | An 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 |
| US6452986B1 (en) | 1999-05-17 | 2002-09-17 | Cellnet Data Systems, Inc. | Detector tolerant of frequency misalignment |
| US6181258B1 (en) | 1999-05-17 | 2001-01-30 | Cellnet Data Systems, Inc. | Receiver capable of parallel demodulation of messages |
| US6163276A (en) | 1999-05-17 | 2000-12-19 | Cellnet Data Systems, Inc. | System for remote data collection |
| WO2000074306A2 (en) | 1999-05-28 | 2000-12-07 | 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 |
| US6836737B2 (en) | 2000-08-09 | 2004-12-28 | Statsignal Systems, Inc. | Systems and methods for providing remote monitoring of consumption for a utility 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 |
| AU2002211469A1 (en) * | 2000-10-06 | 2002-04-15 | 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 |
| JP4193109B2 (ja) | 2000-11-16 | 2008-12-10 | ソニー株式会社 | 情報処理装置および方法、通信装置および方法、通信システムおよび方法、プログラム、並びに記録媒体 |
| SE519560C2 (sv) * | 2000-12-20 | 2003-03-11 | Allgon Mobile Comm Ab | Antennanordning och sätt att justera nämnda antennanordning |
| US6704301B2 (en) | 2000-12-29 | 2004-03-09 | Tropos Networks, Inc. | Method and apparatus to provide a routing protocol for wireless devices |
| US7505426B2 (en) | 2000-12-29 | 2009-03-17 | Tropos Networks | Multi-channel mesh network |
| US6965575B2 (en) | 2000-12-29 | 2005-11-15 | Tropos Networks | Selection of routing paths based upon path quality of a wireless mesh network |
| US7551562B2 (en) | 2000-12-29 | 2009-06-23 | Tropos Networks | Determining bidirectional path quality within a wireless mesh network |
| GB0100093D0 (en) | 2001-01-03 | 2001-02-14 | Vtech Communications Ltd | Adaptive frequency hopping strategy |
| 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 |
| 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 |
| CA2704035C (en) | 2001-03-30 | 2013-01-08 | 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 |
| CA2447515C (en) | 2001-05-02 | 2011-11-08 | Invensys Metering Systems/North America Inc. | Add-on module for utility meters |
| 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 |
| EP1412762A1 (en) | 2001-07-27 | 2004-04-28 | 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 |
| US20030036810A1 (en) | 2001-08-15 | 2003-02-20 | Petite Thomas D. | System and method for controlling generation over an integrated wireless network |
| US6671586B2 (en) | 2001-08-15 | 2003-12-30 | Statsignal Systems, Inc. | System and method for controlling power demand over an integrated wireless network |
| US20030213662A1 (en) * | 2001-08-30 | 2003-11-20 | Fox Robert C. | Inertia valve shock absorber |
| US6604751B2 (en) * | 2001-08-30 | 2003-08-12 | Fox Factory, Inc. | Inertia valve shock absorber |
| 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 |
| US20060259607A1 (en) * | 2001-09-13 | 2006-11-16 | Network Foundation Technologies, Llc | System and method for distributing data over a computer network |
| 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 |
| 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 |
| CN1653755A (zh) * | 2002-04-18 | 2005-08-10 | 沙诺夫股份有限公司 | 用于提供特定联网传感器和协议的方法和装置 |
| 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 |
| US6838867B2 (en) | 2002-06-27 | 2005-01-04 | Elster Electricity, Llc | Electrical-energy meter |
| US7119713B2 (en) | 2002-06-27 | 2006-10-10 | Elster Electricity, Llc | Dynamic self-configuring metering network |
| 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 |
| US20040044555A1 (en) * | 2002-09-04 | 2004-03-04 | Bangs Richard Alan | Systems, apparatus, and methods for facilitating product development |
| 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 |
| 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 |
| US6931445B2 (en) | 2003-02-18 | 2005-08-16 | Statsignal Systems, Inc. | User interface for monitoring remote devices |
| US7068703B2 (en) | 2003-02-18 | 2006-06-27 | Qualcomm, Incorporated | Frequency hop sequences for multi-band communication systems |
| 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 |
| JP4515451B2 (ja) * | 2003-03-24 | 2010-07-28 | ストリックス システムズ インコーポレイテッド | 自己構成と自己最適化とを行うワイヤレスローカルエリアネットワークシステム |
| US7406298B2 (en) | 2003-03-25 | 2008-07-29 | Silver Spring Networks, Inc. | Wireless communication system |
| US7171606B2 (en) | 2003-03-25 | 2007-01-30 | Wegener Communications, Inc. | Software download control system, apparatus and method |
| 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 |
| US7016328B2 (en) | 2003-06-24 | 2006-03-21 | Tropos Networks, Inc. | Method for allowing a client to access a wireless system |
| US7649866B2 (en) | 2003-06-24 | 2010-01-19 | Tropos Networks, Inc. | Method of subnet roaming within a network |
| 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 |
| US7336200B2 (en) * | 2003-09-05 | 2008-02-26 | Itron, Inc. | Data communication protocol in an automatic meter reading system |
| US7376118B2 (en) | 2003-09-05 | 2008-05-20 | Itron, Inc. | System and method for optimizing contiguous channel operation with cellular reuse |
| US7129900B2 (en) | 2003-09-08 | 2006-10-31 | Tantalus Systems Corp. | Meter antenna |
| 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 |
| 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 |
| WO2006004231A1 (en) * | 2004-06-30 | 2006-01-12 | Nuri Telecom Co., Ltd. | Remote meter-reading system and method using duplicated data transmission of packet data transmission and circuit 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 |
| CA2576833C (en) | 2004-08-12 | 2014-10-28 | Interdigital Technology Corporation | Method and system for controlling access to a wireless communication medium |
| 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 |
| US7053770B2 (en) * | 2004-09-10 | 2006-05-30 | Nivis , Llc | System and method for communicating alarm conditions in a mesh network |
| US7676195B2 (en) | 2004-09-10 | 2010-03-09 | Nivis, Llc | System and method for communicating messages 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 |
| 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 |
| US8072945B2 (en) * | 2004-09-24 | 2011-12-06 | Aes Corporation | Link layered networks |
| 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 |
| US7675882B2 (en) | 2005-02-01 | 2010-03-09 | Exs, Inc. | Hierarchical mesh network for wireless access |
| 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 |
| EP1859353A4 (en) | 2005-03-07 | 2012-02-22 | Intel Corp | SELF-ADAPTIVE MUTTON-DELAY FILE TRANSFER PROTOCOL |
| CA2601474C (en) | 2005-03-08 | 2017-04-04 | E-Radio Usa, Inc. | Systems and methods for modifying power usage |
| US7606169B2 (en) * | 2005-03-21 | 2009-10-20 | Rf Monolithics, Inc. | System and method for collecting routing information in a mesh network |
| US7664055B2 (en) * | 2005-03-21 | 2010-02-16 | Rf Monolithics, Inc. | System and method for synchronizing components 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 |
| US7840178B2 (en) | 2005-07-12 | 2010-11-23 | Martin E. Hellman | FM broadcast system competitive with satellite radio |
| US8144027B2 (en) * | 2005-07-12 | 2012-03-27 | Avaak, Inc. | Remote meter reader using a network sensor system and protocol |
| 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 |
| US20070076649A1 (en) * | 2005-09-30 | 2007-04-05 | Intel Corporation | Techniques for heterogeneous radio cooperation |
| 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 |
| 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 |
| US7843834B2 (en) * | 2006-09-15 | 2010-11-30 | Itron, Inc. | Use of minimal propagation delay path to optimize a mesh network |
| 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,202 patent/US7843834B2/en active Active
- 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,199 patent/US7986718B2/en active Active
- 2007-09-11 US US11/900,414 patent/US7848362B2/en active Active
- 2007-09-11 US US11/900,398 patent/US8045537B2/en active Active
- 2007-09-11 US US11/900,411 patent/US8054821B2/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,905 patent/US7764714B2/en active Active
- 2007-09-13 US US11/900,903 patent/US7826398B2/en not_active Expired - Fee Related
- 2007-09-14 CA CA2941447A patent/CA2941447C/en active Active
- 2007-09-14 BR BRPI0722403-6A patent/BRPI0722403A2/pt not_active IP Right Cessation
- 2007-09-14 EP EP20090156664 patent/EP2213985B1/en active Active
- 2007-09-14 BR BRPI0722401-0A patent/BRPI0722401A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0722398-6A patent/BRPI0722398A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0716887-0A patent/BRPI0716887A2/pt not_active IP Right Cessation
- 2007-09-14 CA CA2663505A patent/CA2663505C/en active Active
- 2007-09-14 EP EP20090156694 patent/EP2200372B1/en active Active
- 2007-09-14 BR BRPI0722397-8A patent/BRPI0722397A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0722395-1A patent/BRPI0722395A2/pt not_active IP Right Cessation
- 2007-09-14 EP EP09156700.8A patent/EP2197229B1/en active Active
- 2007-09-14 EP EP20090156659 patent/EP2184940B1/en active Active
- 2007-09-14 WO PCT/US2007/020022 patent/WO2008033514A2/en active Application Filing
- 2007-09-14 CA CA2939873A patent/CA2939873C/en active Active
- 2007-09-14 EP EP09156691.9A patent/EP2207384B1/en active Active
- 2007-09-14 EP EP20090156669 patent/EP2184941B1/en active Active
- 2007-09-14 BR BRPI0722392-7A patent/BRPI0722392A2/pt not_active IP Right Cessation
- 2007-09-14 EP EP20090156662 patent/EP2175675B8/en active Active
- 2007-09-14 BR BRPI0722396-0A patent/BRPI0722396A2/pt not_active IP Right Cessation
- 2007-09-14 US US11/901,293 patent/US7756078B2/en active Active
- 2007-09-14 CA CA2941376A patent/CA2941376C/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 EP EP20090156670 patent/EP2213986B9/en not_active Ceased
- 2007-09-14 BR BRPI0722400-1A patent/BRPI0722400A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0722402-8A patent/BRPI0722402A2/pt not_active IP Right Cessation
- 2007-09-14 AU AU2007294728A patent/AU2007294728B2/en active Active
- 2007-09-14 EP EP20090156658 patent/EP2182654B1/en active Active
- 2007-09-14 BR BRPI0722393-5A patent/BRPI0722393A2/pt not_active IP Right Cessation
- 2007-09-14 EP EP20090156681 patent/EP2192706B1/en active Active
- 2007-09-14 BR BRPI0722394-3A patent/BRPI0722394A2/pt not_active IP Right Cessation
- 2007-09-14 BR BRPI0722399-4A patent/BRPI0722399A2/pt not_active IP Right Cessation
- 2007-09-14 CA CA2992078A patent/CA2992078C/en active Active
- 2007-09-14 EP EP07838257.9A patent/EP2059911B1/en active Active
- 2007-09-14 CA CA2939883A patent/CA2939883C/en active Active
- 2007-09-14 EP EP09156673.7A patent/EP2211575B1/en active Active
- 2007-09-14 BR BRPI0722404-4A patent/BRPI0722404A2/pt not_active IP Right Cessation
- 2007-09-14 MX MX2009002801A patent/MX2009002801A/es active IP Right Grant
- 2007-09-14 EP EP20090156654 patent/EP2182762B1/en active Active
-
2009
- 2009-06-23 AU AU2009202519A patent/AU2009202519A1/en not_active Abandoned
- 2009-06-23 AU AU2009202517A patent/AU2009202517B2/en active Active
- 2009-06-25 AU AU2009202551A patent/AU2009202551B2/en active Active
- 2009-06-25 AU AU2009202550A patent/AU2009202550B2/en active Active
- 2009-06-26 AU AU2009202590A patent/AU2009202590B2/en active Active
- 2009-06-26 AU AU2009202589A patent/AU2009202589B2/en active Active
- 2009-07-06 AU AU2009202735A patent/AU2009202735B2/en active Active
- 2009-07-06 AU AU2009202748A patent/AU2009202748B2/en active Active
- 2009-07-06 AU AU2009202738A patent/AU2009202738B2/en active Active
- 2009-07-06 AU AU2009202744A patent/AU2009202744B2/en active Active
- 2009-07-06 AU AU2009202733A patent/AU2009202733B2/en not_active Ceased
- 2009-07-06 AU AU2009202736A patent/AU2009202736B2/en active Active
- 2009-07-06 AU AU2009202732A patent/AU2009202732B2/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,413 patent/US8907812B2/en active Active
- 2011-11-14 US US13/295,435 patent/US20120119923A1/en not_active Abandoned
-
2013
- 2013-02-28 US US13/780,001 patent/US8848571B2/en active Active
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11665030B2 (en) * | 2019-03-29 | 2023-05-30 | Denso Corporation | Relay device |
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0716887A2 (pt) | protocolo de lan de rf de mediÇço e utilizaÇço e gerencimento de cÉlula/nà |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] |
Free format text: REFERENTE A 9A ANUIDADE. |
|
| B08K | Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette] |
Free format text: EM VIRTUDE DO ARQUIVAMENTO PUBLICADO NA RPI 2385 DE 20-09-2016 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDO O ARQUIVAMENTO DO PEDIDO DE PATENTE, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013. |