CA2308819A1 - Self organizing network architecture - Google Patents
Self organizing network architecture Download PDFInfo
- Publication number
- CA2308819A1 CA2308819A1 CA002308819A CA2308819A CA2308819A1 CA 2308819 A1 CA2308819 A1 CA 2308819A1 CA 002308819 A CA002308819 A CA 002308819A CA 2308819 A CA2308819 A CA 2308819A CA 2308819 A1 CA2308819 A1 CA 2308819A1
- Authority
- CA
- Canada
- Prior art keywords
- meter
- lan
- data
- concentrator
- signal strength
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- 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/02—Topology update or discovery
Abstract
Wireless connectivity holds the promise to revolutionize every aspect of modern activity. The pace of conversion from a "Wired" world to a "Wireless" world continues to accelerate, with a virtually unlimited number of applications and opportunities available to be exploited. The restrictions to this movement have been more economic than technical in nature. The fundamental collapse of the cost of technology and associative technological innovation has strongly influenced the entry economics of wireless products and services in general.
Description
Self-Organizing Network Architecture (SONA) Ab3~act Wireless con ivity holds the promise to revol ' a every aspect of modern activity. The pac conversion fro fired" world to a "Wireless" world continues to accelerate, ' h ually unlimited number of applications and opportunities availabl a oited. The restrictions to this movement have been more ec is than technica ' ature. The fundamental collapse of the cost o chnology and associative to logical innovation has strongly i nced the entry economics of wireless produc services in general.
Economic Gating Factors for Wireless Adoption Wireless RF technology in its earliest stages was entirely Wide Area Network (WAN) based. Microwave Relay, Satellite and Cellular services proved to be key enabling technologies for the movement of high value voice, video and data services. The key economic barrier that all three technologies overcame was the physical cost of providing service over both distance and broadly diverse location, hence the use of the WAN nomenclature. Over the years, a number of new WAN alternatives have proliferated, reducing the cost of entry incrementally as each new competitive WAN technology like PCS, Reflex 50, CDPD, etc.
entered the market. As valuable and useful as WANs have proven to be and even with dramatic enhancements in the price/performance of WANs in general, they have not proven to be the final answer for lower value wireless transactions.
The Transition from Circuit Switched to Packet Switched Networks Another economic breakthrough for wired and wireless services was the migration of most new networks away from circuit switched to packet switched data transmission. This transition opened up many new markets for transactions that benefited from the increased efficiency of optimized bandwidth utilization.
This new generation of hardware and packet driven protocols, such as TCPIIP
has more or less completed the conversion of the "Last mile" economy that used to be dominated by wired service to the "Last Byte" economy that is increasingly dominated by low cost wireless services. The "Last Byte" refers to the search for new technologies that can profitably capture the vast volumes of low value and comparatively smaller packet transactions that represent the next wave of opportunity for wireless data services. These transactions needed to be captured and managed locally to be of economic consequence for wireless data services.
For localized replacement of close proximity wired services, new generations of wireless Local Area Network (LAN) technologies have developed. They now represent an excellent way to deliver low value wireless transactions through to packet switched WANs. Wireless LAN technology costs in turn have collapsed to the point where very broad adoption of LAN technology has occurred in midrange to lower value services applications. It is now common for WAN and LAN technologies to be interfaced to enhance wireless price/performance economics for entry into this vast array of lower value market applications.
This new strategy works economically by concentrating a substantial number of lower value transactions at the LAN layer into larger, higher value transactions for transport through the WAN. The large volume of LAN devices being utilized continues to collapse the costs of LAN devices.
Synchronous Versus Asynchronous Transmission One of the main differences between a WAN and a LAN technology is the ability to manage asynchronous transmission. At the device level, the ability to negotiate a network connection in an asynchronous manner adds significantly to the cost of the WAN device. For a WAN to be of practical use, it must manage requests for transmission it receives from these remote transceivers. LAN's on the other hand typically administer transmissions on the LAN in a synchronous manner, whereby a LAN master polls other LAN devices for data waiting for transmission. In this manner, any number of LAN devices within an area of RF
influence can be managed effectively with much lower component costs. There is a limit however to the practical number of devices that can be effectively managed in this manner.
There are many circumstances where the ability to deliver unscheduled information such as alarms or status information, require an effective method of delivering this information quickly. In a polled environment, the status or alarm information only gets sent as often as the device is polled. In a WAN
environment, this same information can only be sent when the WAN device's request to send is acknowledged. There is a practical latency to each of these scenarios based on the number of transceivers involved. The fundamental issues to be resolved for WAN or LAN selection purposes relate completely to the price/performance requirements of the remote devices and the network layer chosen.
Where certainty is an advantage or a requirement, a polled strategy is invariably utilized that guarantees that the system operator will know immediately if there are any transceivers failing to respond, rather than waiting for the device to send information. In a polled LAN strategy, there is a limitation to the number of devices that can cohabitate on a single LAN, is based on the length of time it takes for the LAN master to poll the individual transceivers in the LAN.
Synchronous polling of devices also limits RF traffic to the communicating LAN
pair. This reduction in locally generated RF emissions, reduces contention.
The Last Fundamental Barriers to AMR
Today, for any high volume low value transaction opportunity, the main economic barrier is no longer the price/performance capabilities of the WAN portion of the WAN/LAN system or the cost of LAN devices. It is now, rather the costs of
Economic Gating Factors for Wireless Adoption Wireless RF technology in its earliest stages was entirely Wide Area Network (WAN) based. Microwave Relay, Satellite and Cellular services proved to be key enabling technologies for the movement of high value voice, video and data services. The key economic barrier that all three technologies overcame was the physical cost of providing service over both distance and broadly diverse location, hence the use of the WAN nomenclature. Over the years, a number of new WAN alternatives have proliferated, reducing the cost of entry incrementally as each new competitive WAN technology like PCS, Reflex 50, CDPD, etc.
entered the market. As valuable and useful as WANs have proven to be and even with dramatic enhancements in the price/performance of WANs in general, they have not proven to be the final answer for lower value wireless transactions.
The Transition from Circuit Switched to Packet Switched Networks Another economic breakthrough for wired and wireless services was the migration of most new networks away from circuit switched to packet switched data transmission. This transition opened up many new markets for transactions that benefited from the increased efficiency of optimized bandwidth utilization.
This new generation of hardware and packet driven protocols, such as TCPIIP
has more or less completed the conversion of the "Last mile" economy that used to be dominated by wired service to the "Last Byte" economy that is increasingly dominated by low cost wireless services. The "Last Byte" refers to the search for new technologies that can profitably capture the vast volumes of low value and comparatively smaller packet transactions that represent the next wave of opportunity for wireless data services. These transactions needed to be captured and managed locally to be of economic consequence for wireless data services.
For localized replacement of close proximity wired services, new generations of wireless Local Area Network (LAN) technologies have developed. They now represent an excellent way to deliver low value wireless transactions through to packet switched WANs. Wireless LAN technology costs in turn have collapsed to the point where very broad adoption of LAN technology has occurred in midrange to lower value services applications. It is now common for WAN and LAN technologies to be interfaced to enhance wireless price/performance economics for entry into this vast array of lower value market applications.
This new strategy works economically by concentrating a substantial number of lower value transactions at the LAN layer into larger, higher value transactions for transport through the WAN. The large volume of LAN devices being utilized continues to collapse the costs of LAN devices.
Synchronous Versus Asynchronous Transmission One of the main differences between a WAN and a LAN technology is the ability to manage asynchronous transmission. At the device level, the ability to negotiate a network connection in an asynchronous manner adds significantly to the cost of the WAN device. For a WAN to be of practical use, it must manage requests for transmission it receives from these remote transceivers. LAN's on the other hand typically administer transmissions on the LAN in a synchronous manner, whereby a LAN master polls other LAN devices for data waiting for transmission. In this manner, any number of LAN devices within an area of RF
influence can be managed effectively with much lower component costs. There is a limit however to the practical number of devices that can be effectively managed in this manner.
There are many circumstances where the ability to deliver unscheduled information such as alarms or status information, require an effective method of delivering this information quickly. In a polled environment, the status or alarm information only gets sent as often as the device is polled. In a WAN
environment, this same information can only be sent when the WAN device's request to send is acknowledged. There is a practical latency to each of these scenarios based on the number of transceivers involved. The fundamental issues to be resolved for WAN or LAN selection purposes relate completely to the price/performance requirements of the remote devices and the network layer chosen.
Where certainty is an advantage or a requirement, a polled strategy is invariably utilized that guarantees that the system operator will know immediately if there are any transceivers failing to respond, rather than waiting for the device to send information. In a polled LAN strategy, there is a limitation to the number of devices that can cohabitate on a single LAN, is based on the length of time it takes for the LAN master to poll the individual transceivers in the LAN.
Synchronous polling of devices also limits RF traffic to the communicating LAN
pair. This reduction in locally generated RF emissions, reduces contention.
The Last Fundamental Barriers to AMR
Today, for any high volume low value transaction opportunity, the main economic barrier is no longer the price/performance capabilities of the WAN portion of the WAN/LAN system or the cost of LAN devices. It is now, rather the costs of
2 physical deployment, implementation and operation of the LAN devices themselves. This is especially true in applications like Automated Meter Reading (AMR) where the sheer volume of units involved creates logistical difficulties of a considerable magnitude.
One of the most difficult requirements in overall WAN/LAN deployment and implementation is to securely effect network connection, address assignment and subsequent transaction (data) routing from LAN devices to the WAN. GPS has helped many to locate and manage these broadly dispersed assets more effectively. What is now needed to eliminate the last fundamental barriers to low value wireless transactions is to have the LAN devices organize, connect and address themselves efficiently. These capabilities would overcome the "Organizational Barrier" and make AMR truly economic as a standalone application.
AMR is certainly one of the most attractive ways to capture low value transactions that occur in significant volumes. AMR also represents a practical way to access a vast array of other potential applications that could be considered economic when the appropriate price/performance strategy is employed.
Many companies have recognized the potential for these AMR driven wireless networks to support the provision of a broad range of low cost transaction services. Emerging AMR strategies typically contemplate the use of the LAN
module employed in the meter, as a sort of wireless gateway for the transport of numerous other transactions that could contribute services revenue. While this strategy offers a way of generating theoretical support revenues that accrue to the AMR network owner, regulatory and revenue uncertainty continue to make it difficult to use this additional economic support as the basis for adoption.
Today, this potential revenue offers the only offsetting economics to support the additional costs of organizing the LAN portion of large AMR networks.
Eliminating the Organizational Barrier to entry will drive adoption of wireless AMR
network topologies as well as the adoption of a vast array of associative services.
SONA (Self Organizing Network Architecture) will be a key enabling technology, which will unlock the potential for high volumes of low value transactions.
SONA
transactions will also displace the commercial position of a vast number of higher value WAN transaction opportunities that exist within SONA coverage due to the low entry cost of the devices and the reduction in WAN airtime costs.
One of the most difficult requirements in overall WAN/LAN deployment and implementation is to securely effect network connection, address assignment and subsequent transaction (data) routing from LAN devices to the WAN. GPS has helped many to locate and manage these broadly dispersed assets more effectively. What is now needed to eliminate the last fundamental barriers to low value wireless transactions is to have the LAN devices organize, connect and address themselves efficiently. These capabilities would overcome the "Organizational Barrier" and make AMR truly economic as a standalone application.
AMR is certainly one of the most attractive ways to capture low value transactions that occur in significant volumes. AMR also represents a practical way to access a vast array of other potential applications that could be considered economic when the appropriate price/performance strategy is employed.
Many companies have recognized the potential for these AMR driven wireless networks to support the provision of a broad range of low cost transaction services. Emerging AMR strategies typically contemplate the use of the LAN
module employed in the meter, as a sort of wireless gateway for the transport of numerous other transactions that could contribute services revenue. While this strategy offers a way of generating theoretical support revenues that accrue to the AMR network owner, regulatory and revenue uncertainty continue to make it difficult to use this additional economic support as the basis for adoption.
Today, this potential revenue offers the only offsetting economics to support the additional costs of organizing the LAN portion of large AMR networks.
Eliminating the Organizational Barrier to entry will drive adoption of wireless AMR
network topologies as well as the adoption of a vast array of associative services.
SONA (Self Organizing Network Architecture) will be a key enabling technology, which will unlock the potential for high volumes of low value transactions.
SONA
transactions will also displace the commercial position of a vast number of higher value WAN transaction opportunities that exist within SONA coverage due to the low entry cost of the devices and the reduction in WAN airtime costs.
3 RF Technical Challenges to Broad Network Implementation The difficulties inherent in the broad implementation of any RF technology are that RF device emplacement and the resulting RF path expectations are at best a theoretical expectation based on sound engineering practice. The localized RF
environments within the larger RF domain will in practice be either slightly better or worse than the theoretical average RF path expectation. This uncertainty has created problems for RF engineers who need to design network architectures for broadly dispersed transceivers. To add to this difficulty, the localized density of transceivers varies considerably, especially in a utility meter AMR
deployment.
Device-to-device RF based communications are optimally accomplished by using the lowest amount of signal required to maintain acceptable signal to noise ratios. Managing great variations in distance between transceivers is normally handled by manipulating transmission power and antenna placement and selection on a case-by-case basis. This is an impractibly complex and expensive process to manage individually in large deployments. To be economically viable, all of the transceivers must be identical in their characteristics. It should also be expected that personnel unskilled in RF would perform their implementation.
The biggest long-term problem faced in the RF environment is that it can and will change over time. Vegetation growth, new structures, and undetermined external RF background noise will eventually impact portions of the RF
environment. In normal circumstances, path profile studies are performed to characterize the RF environment prior to deployment to create some certainty of the theoretical performance that can be achieved. A path profile study of the granularity necessary to ensure success in a high volume of widely distributed RF devices is not economically viable, if possible at all, given the RF
environments propensity to be different at the time of deployment than during testing.
In most circumstances, only the highest value applications can justify individual path profiles between transceivers. In an AMR deployment, economics do not allow this type of approach. WAN concentrators are usually pole or tower mounted, utilizing existing utility assets and leased locations to create an economically viable line of sight path between LAN devices and the WAN/LAN
concentrators. WAN/LAN concentrator distribution requires a considerable amount of detailed engineering and repeated follow up after deployment to get a system that is reliably operational. This would become a much more manageable scenario if the meter based LAN modules could act as network routers, acting as secure RF paths between themselves and the WAN/LAN
concentrators. In a small LAN grouping of known locations and positions, such as a local office environment, reasonably successful network routing can be achieved economically. However, in a typical million point AMR deployment, the physical cost of mapping out and testing individual network routing assignments becomes a complex undertaking involving a great number of skilled technicians.
environments within the larger RF domain will in practice be either slightly better or worse than the theoretical average RF path expectation. This uncertainty has created problems for RF engineers who need to design network architectures for broadly dispersed transceivers. To add to this difficulty, the localized density of transceivers varies considerably, especially in a utility meter AMR
deployment.
Device-to-device RF based communications are optimally accomplished by using the lowest amount of signal required to maintain acceptable signal to noise ratios. Managing great variations in distance between transceivers is normally handled by manipulating transmission power and antenna placement and selection on a case-by-case basis. This is an impractibly complex and expensive process to manage individually in large deployments. To be economically viable, all of the transceivers must be identical in their characteristics. It should also be expected that personnel unskilled in RF would perform their implementation.
The biggest long-term problem faced in the RF environment is that it can and will change over time. Vegetation growth, new structures, and undetermined external RF background noise will eventually impact portions of the RF
environment. In normal circumstances, path profile studies are performed to characterize the RF environment prior to deployment to create some certainty of the theoretical performance that can be achieved. A path profile study of the granularity necessary to ensure success in a high volume of widely distributed RF devices is not economically viable, if possible at all, given the RF
environments propensity to be different at the time of deployment than during testing.
In most circumstances, only the highest value applications can justify individual path profiles between transceivers. In an AMR deployment, economics do not allow this type of approach. WAN concentrators are usually pole or tower mounted, utilizing existing utility assets and leased locations to create an economically viable line of sight path between LAN devices and the WAN/LAN
concentrators. WAN/LAN concentrator distribution requires a considerable amount of detailed engineering and repeated follow up after deployment to get a system that is reliably operational. This would become a much more manageable scenario if the meter based LAN modules could act as network routers, acting as secure RF paths between themselves and the WAN/LAN
concentrators. In a small LAN grouping of known locations and positions, such as a local office environment, reasonably successful network routing can be achieved economically. However, in a typical million point AMR deployment, the physical cost of mapping out and testing individual network routing assignments becomes a complex undertaking involving a great number of skilled technicians.
4 The SONA Solution During installation of the LAN meter nodes, the installer captures a GPS
reading.
These GPS coordinates, the meter ID, Customer ID and a unique password are placed in a mobile data unit, carried by the installer for subsequent download to a database for verification and later reuse. Essentially, this information lets the utility know where every customer is, the meter type, ID, etc. The WAN/LAN
system can then use this information locally to create what we are now calling a "Self Organizing Network Architecture" (SONA).
SONA Device Descriptions There are essentially two basic types of SONA devices:
~ The LAN node, or Local Area Network transceiver.
~ The WAN/LAN concentrator, which incorporates a WAN transceiver, WAN/LAN interface board and a LAN node.
The LAN node incorporates a 902-928 MHz FHSS radio (or Other Radio/Frequency), with on board microprocessor, flash memory, power supply, and onboard omni directional antenna. For meter applications, either a serial port connection or a pulse counting module is incorporated into the meter prior to installation. Any LAN node can become a WAN/LAN concentrator when a WAN
transceiver and WAN/LAN interface are installed. Any type of WAN connection could be used, and as such is not a key factor in SONA deployment, other than its capacity to manage anticipated WAN transaction requirements. Typical WAN
connections could include Two Way paging, CDPD, GSM, IDEN or RDLAP or the newer Broadband network transceiver modules, as examples.
The single chip CMOS LAN transceiver section (or Other implementation) can be safely operated at power levels between 200 to 300 milliwatts, without incorporating additional amplifier circuitry, depending on overall RF circuit attenuation. The transceiver section of the LAN node can have its power level set through a binary scale of 0 to 255, via the onboard processor, allowing a wide variance in transceiver output.
Every LAN node incorporates sufficient memory to include the Media Access Control layer functions required to effectively act as both a LAN node and a WAN/LAN master. Additional memory is reserved for routing table information, local data storage, parameter storage, as well as any executable code required for local applications management, such as tracking pulses from the meter.
Each LAN module also supports the attachment of Sub-LAN devices/services through a locally managed Sub-LAN addressing strategy. In Sub-LAN service, the local LAN node acts as a master to other co-located LAN devices that negotiate Sub-LAN assignment to the LAN node, which then effectively operates as a Sub-LAN master, routing data through to the WAN.
SONA Registration Management Every device in the deployment, once it gets installed, has its GPS
coordinates loaded into memory via communication with a GPS/LAN module held by the installer or through an IRDA port or other means. WAN/LAN concentrators are distributed in a systematic fashion, consistent with WAN to LAN ratio requirements. i.e., every 200-240 LAN node devices a WAN/LAN concentrator gets implemented. The exact ratio could be any number of devices, but is strongly influenced by the amount of data that needs to be transported by the WAN. This WAN emplacement can, without great difficulty, ensure that WAN
devices are placed evenly within the overall LAN node distribution.
The LAN node address structure uses a single address byte that supports 255 individual addresses, which is incorporated into the protocol packet for transmission. A second address byte incorporated into the protocol packet allows for the attachment of 255 Sub-LAN addresses. Distribution ratios during initial deployment of the network should necessarily contemplate new addresses being assigned over time. The initial ratio of WAN/LAN to LAN devices is best kept between 200 and 240 units depending on average device densities and the potential for higher densities of devices in the future. A number of addresses are reserved for maintenance and supervisory services. Maintaining a consistent set of reserve addresses throughout the domains provides a method for mobile LAN
devices to be used by Utility personnel for local interrogation of meters and other transaction services. This methodology also allows recovery of meter data when a WAN device fails or if the WAN network is unavailable via a LAN transceiver using a reserve address to make a LAN connection anywhere in the network.
Every WAN/LAN concentrator and LAN node starts listening actively once it is installed and GPS located. The GPS coordinates, Device ID, Meter ID and Customer ID as well as a password for access are downloaded into the Network Management System (NMS) from the installers portable units. Every device deployed will only respond to a packet that incorporates the unique LAN ID, password and GPS coordinate of each LAN node or WAN/LAN concentrator.
The NMS incorporates this information into a GPS/GIS oriented database. This database is structured to support an algorithm that organizes LAN nodes that surround each WAN/LAN concentrator into individual domains. The WAN device ID is used to give each domain a unique ID. If a WAN device fails or is changed over to a new network, the domain name changes to the new WAN device ID.
The average domain size is based on the ratio of WAN/LAN concentrators to LAN nodes deployed.
Since the WAN device ID is typically either a unique 32 bit or a 64 bit number, depending on the type of WAN employed, there are virtually an unlimited number of domains that can be created.
At this initial stage, the domain file created is still a theoretical extrapolation, based on the GPS information provided. This file determines the LAN nodes that the WAN/LAN concentrator is expected to capture during its SONA registration sequence to enable effective territory wide SONA network coverage. The NMS
creates a domain file based on this extrapolation and downloads this file to the WAN/LAN concentrator that will operate as the domain master for the LAN nodes nominated by NMS.
The domain file provides the LAN node ID, the GPS coordinate of the LAN node and the password assigned during installation. As part of the domain organization strategy, all of the LAN nodes to be captured are assigned a position in a defined acquisition sequence, based on the relative distance between the WAN/LAN concentrator and the individual nodes. The sequence also contemplates the relative vector angle of the LAN nodes in reference to the WAN/LAN concentrator. This effectively forces a spiral structure to the sequence starting from the LAN node closest to the WAN/LAN concentrator and ending at the most distant.
The WAN/LAN concentrator transmits its first request at a preset power level.
This power level is a theoretical calculation of the transmission power required for secure transmission between the two devices. The power level versus distance algorithm is a preset value, based on the known capabilities of the transceiver. The device meant to receive the packet sends its response at the same power level. Assuming that the bit error rate is acceptable, the WAN/LAN
concentrator then registers the device. Registration of the node, assigns the domain, sets the device status, sets the power level for transmissions, and time synchronizes the device to the network. If the polled device does not respond, then the message is sent again at a higher power level. This methodology guarantees that the lowest practical transmission power is used to arbitrate and register each new LAN node in the sequence. (A more detailed description of Power management is provided later in this document.) Upon receipt of a valid transmission from a polled meter in the sequence, the WAN/LAN concentrator registers the node. During registration, the LAN node is given a unique LAN address that corresponds to its number in the domain polling sequence. The power level needed to establish a secure RF connection and the bit error rate achieved are also written into the table upon registration. A
Received Signal Strength Indication (RSSI) can also be incorporated if available.
Once a LAN node is registered into a WAN/LAN domain, it ignores all transmissions except those registered to that particular domain. The WAN/LAN
concentrator repeats this routine for every LAN node on its domain listing. In most residential applications, low meter densities or local RF path obstructions will not allow the capture of all of the LAN nodes in the domain list during the initial capture sequence. When the full domain list of LAN nodes have been either captured and registered or polled without achieving capture, the WAN/LAN
concentrator sends a file to the NMS comprised of the successfully captured LAN
nodes, the power levels used and the achieved bit error rates.
The NMS places this information into the main database. The power level and achieved bit error rate information is the equivalent of an automated path profile study between the WAN/LAN concentrator and the captured LAN nodes. This data can be used to interpret the local RF environment by the NMS. It can also be used for comparative analysis in the future to determine whether transceiver degradation or RF path degradation is impacting LAN node performance over time.
The NMS then overlays the resulting "path profiles" between the WAN/LAN
concentrator and the individually captured LAN nodes onto the GPS/GIS map area that contains the remaining LAN nodes that were not captured during the initial registration sequence. This information provides a detailed understanding of the local RF environment surrounding the captured devices. This data also provides an excellent statistical probability of the quality of the RF
environment in those areas in the domain where LAN nodes failed to respond in the initial sequence. An algorithm that interprets this information can then select a subset of the captured LAN nodes that have the highest probability to capture the balance of the LAN nodes that were not captured during the initial SONA
sequence.
A new download file is then constructed by the NMS, based on the results of the data interpretation. This file contains the sequence numbers of the LAN nodes chosen to act as LAN node concentrators. A LAN node concentrator acts effectively as a repeater between LAN nodes that failed to register during the primary SONA sequence and the WAN/LAN concentrator. The file also describes the most probable polling path or route to each LAN node that failed to respond during the initial registration sequence. This file is incorporated into a routing table. The routing table describes the proposed path for each LAN node that was not captured during the original polling sequence.
The WAN/LAN concentrator contacts each LAN node selected for use as a LAN
node concentrator and reregisters the LAN node as a LAN concentrator. During the reregistration a file containing a list of LAN node addresses is sent that represent LAN nodes that the concentrator is expected to manage routing for.
Whenever the WAN/LAN concentrator for the domain sends a message for one of these addresses, the LAN concentrator that has received one of these addresses will repeat the message at the power level indicated by the registration packet sent by the WAN/LAN concentrator. The LAN concentrator will repeat any response from the LAN node being contacted, since its address is incorporated in the return packet. The capture strategy employed by the WAN/LAN concentrator during the initial sequence is employed as before, with the only difference being that it factors in the additional delay of the repeater function into its capture strategy. Any LAN nodes captured during the new registration sequence are registered and given their LAN address to the domain as before. Upon completion of the new registration sequence, the power level and bit error rates of the newly acquired LAN nodes are sent to NMS for incorporation into the database and the GPS/GIS path profile map for the domain.
In most circumstances, this secondary capture will complete registration for the domain. In circumstances where this is not the case, the NMS will reinterpret the newly gathered path profile data, and either select newly captured nodes or alternate nodes to be used as LAN concentrators to capture the balance of the missing LAN nodes from the original domain sequence.
The same registration strategy is employed as for the secondary capture, with a key difference being that more than one LAN concentrator will be part of the route. The new LAN node addresses are added to the repeater listing of those LAN nodes that become part of the path. The WAN/LAN concentrator factors in the delay of the additional repeaters in the path, as before.
This process is repeated until all LAN nodes in the domain are captured. At the NMS, supervisory personnel can monitor the progress of the domain registrations. The number of registration sequences employed (or the maximum route length) can be preset by authorized personnel to a preset limit. This allows the propagation of the network within the domain to be monitored by expert supervision. This approach would allow the user to adjust algorithm parameters, based on analysis of gathered path data, adjust power levels used and follow up on situations indicating inoperable or otherwise unavailable devices, to essentially manage network propagation in an optimal manner.
In circumstances where a preferred propagation strategy is required, such as on the edge of WAN coverage, a manually generated domain selection could be sent. Rather than the WAN/LAN concentrator being in the geographic center of the domain, it could be at the edge of the domain, where WAN network coverage exists. This method could also be used to force propagation solely to fill gaps in the SONA coverage, or redefine coverage at a later date.
SONA Transmit Power Management FCC guidelines for 902-928 FHSS radio modems allow a maximum power level of one watt. A key aspect of the SONA strategy is that the LAN node transmits at either a predetermined or programmable power level. Few AMR deployments utilize the full power allowed by the license, due to the additional cost of the transceiver when amplification is required. Also, the general difficulty of managing contention and packet collisions increases in high densities of devices as the transmission power increases. Power output is either based on the theoretical transmission requirements for successful acquisition of the packet by devices within the target distance or a value supplied by NMS based on other influencing characteristics of the RF environment. A power level consistent with the known propagation characteristics and therefore the transmit power requirements for the distance value, might be 1 to 10 milliwatts depending on the attenuation of the device antennae. (Note: A key consideration of FHSS is that unregistered devices must always operate on a default FHSS hopping sequence before final arbitration and registration into a new domain. Once registration is complete, and the appropriate numbers of LAN nodes have been acquired, assigning unique hopping sequences for co-located domains, will reduce local RF collisions and contention. This reassignment is managed through the NMS) The registration packet incorporates the binary power setting of the transmit power used for transmission. If the first attempt does not successfully receive a valid acknowledgement transmission from the LAN node contacted, the WAN/LAN device retransmits at the next staged increment in power level, for example 10 to 100 milliwatts. In the case where a repeater or repeaters are involved, the same case holds true. Any repeaters involved use the previously established power transmit level for retransmission of the packet message. It is important to note that this could mean that it uses different power levels for retransmission depending on the LAN address of the recipient.
Note:
Many ISM band transceiver chip sets also incorporate a RSSI (Received Signal Strength Indication) capability. This information can also be used to dynamically select power level. RSSI looks at the signal power of received transmissions.
Devices could negotiate power levels until minimum signal to noise ratios are achieved. RSSI is also a simple way to identify signal degradation over time, and could be used to have the individual devices manage their own power levels using the RSSI indication as the basis for a transmit power set point.
Missing LAN node Arbitration and Domain Registration In large volume device deployments, it must be expected that some number of devices will exist in or surrounding WAN/LAN concentrator domains that did not acquire domain registration. The domain sequence is then compared to the registration information sent by the WAN/LAN concentrator. The NMS then generates a list of "missing" nodes for supervisory intervention. NMS can also be used to generate alternate routing strategies to acquire missing nodes, by comparing known GPS coordinates of missing devices with known RF paths and vector information of registered LAN and WAN/LAN concentrators. In many circumstances, devices along Domain boundaries may need to be reassigned to a new domain to achieve registration. NMS can also manage redistribution of LAN nodes to balance loading evenly among domains, by reassigning LAN
nodes to co-located domains.
SONA Maintenance Each LAN node now has a known path back to the WAN/LAN concentrators.
When the WAN/LAN concentrator is unable to transmit or receive to any LAN
node due to either a transceiver failure or a reduction in RF path, it notifies the NMS. The NMS in turn, initiates a network repair sequence. The sequence follows a similar pattern to the SONA sequence. In most circumstances, the first repair attempt will simply increase the transmit power of the sending transceiver to see if a response can be achieved. If increasing transmit power does not repair the network connection, then NMS can reroute to another LAN node that represents another probable path/route in the domain. Failure to complete any transaction generates a failure packet, which is sent to a log file and then passed onto the system administrator. NMS can reassign routes automatically or be rerouted manually if required or desirable. NMS manages WAN/LAN
concentrator activity, following up on any failure and generates a service report recommendation for maintenance follow-up.
In the case of a device failure, where replacement is required, SONA
registration is simplified. The new installation information is used to update the database, and the original registration information is used by the WAN/LAN concentrator of the domain to register the newly installed LAN node.
The WAN/LAN concentrator monitors network health during polling, comparing bit error rates of the LAN nodes registered in its domain table to determine certainty of the established routing. Circumstances where transmit power has been increased to ensure network connection, or where rerouting has proven necessary are updated in both the NMS database and the WAN/LAN
concentrator's routing tables as part of routine network management. NMS can initiate a forced domain registration scan on demand where circumstances warrant, such as a natural disaster or in a managed network maintenance strategy.
SONA Sub-LAN Addressing and Registration Sub-LAN devices must also be considered in the overall network strategy. Each LAN node is capable of managing up to 256 devices as an address layer below the SONA LAN node using a single address byte. This second byte is part of all LAN addresses. In circumstances where the LAN node is being polled, the second byte is always represented as 0. Addresses 1 to 255 on the second byte are reserved for Sub-LAN devices. The primary economic rationale for a Sub-LAN address is to support localized associated services at very low transmission levels. Associated services are given a unique assignment ID. The assignment ID limits the protocol overhead required to manage the transactions through the network. A more complete description of the data structure and data management rationale for both LAN and Sub-LAN devices can be found in Appendix "A" attached. This assignment ID also lets NMS know the ultimate destination of data packets, which for this type of information might be a completely different database structure in a different location or Internet address than primary services. The ID also identifies the construction of the packet and the way information is organized within the packet. In this way, the routing of data and the organization, structure and home destinations of the information can be completely separate, yet efficiently defined and managed.
Gas and Water Metering as examples of Sub-LAN Services Since power is best accessed by installation of an electric meter as a "gateway"
device, it is most likely to be the method of entry for a LAN node. The most likely associated services that could be attached to the Electric meter LAN node are other metering activities such as Gas and Water metering. Supplying a source of electric service for power for Gas or Water AMR is extremely cost prohibitive.
Gas and Water metering require an aggressive power conservation strategy to be used to extend battery life. The ultimate strategy is to have battery life be equal to the useful service life of the installed meter. Typically, battery life requires the meter to keep the transceiver section turned off, except during scheduled intervals where meter information is uploaded to a local LAN node for routing to a WAN/LAN node.
Installation of the sub-meter, whether Gas or Water, is performed identically to Electric meter installation, other than the mechanical portion of the installations.
The installation information, including GPS coordinates, LAN ID, meter ID, Customer ID and unique password, is downloaded to the appropriate supervisory system and then subsequently to the NMS database. A Sub-LAN device is sent a message from the NMS via the WAN/LAN concentrator and LAN nodes whose coordinates most closely equate to the GPS location of the Gas or Water meter.
Since data organization and data routing are completely separate, the LAN node next door to the Gas meter could be used rather than the LAN node of the house where the Gas meter was installed. Managing RF efficiency and data integrity is best handled through the closest LAN node.
The NMS generates routing instructions by a review of the existing path profile information. A Sub-LAN Address incorporating the LAN node address of the selected LAN node is generated and sent to the WAN/LAN concentrator. Once the WAN/LAN concentrator has acquired the routing information, it reregisters the LAN node as a Sub-LAN master using a simplified SONA acquisition sequence. The LAN node, acting as a Sub-LAN master then transmits a packet that includes the Gas or Water meter LAN ID and the password. The Sub-LAN
Gas or Water meter is then given its new Sub-LAN address. As part of the registration process, a time date stamp is sent to the meter to schedule activation of its receiver section. The Sub-LAN master node, which also synchronizes itself to the Gas or Water meter LAN node's activation schedule, sends a request for information to the meter at the appointed time. Once the new meter data is received, it sends an acknowledgement packet containing a new time stamp. In this way, time synchronization is maintained between the LAN node and the Sub-LAN node at all times, and transceiver activity is limited to a minimum, extending battery life. This same strategy can be used for any battery powered Sub-LAN
service.
Other Sub-LAN Services There will be two other types of Sub-LAN services. Fixed Sub-LAN services such as phone cut-line detection or load regulation such as A/C, water heating, etc. would be good examples of the first. The second would be the support of mobile transceivers operating as Sub-LAN subscribers. Fixed Sub-LAN services would operate identically to sub metering, except that a power conservation strategy would not be employed. Conceptually, randomly adopted Sub-LAN
services would be difficult to integrate as GPS located nodes. This type of services node would operate within the SONA architecture as a locally assigned and registered device. .To limit overhead and contention this registration would add the service as a Sub-LAN domain participant. NMS will manage this strategy in a similar fashion to standard SONA, using theoretical diversity based on known RF paths and LAN node locations as the grouping strategy rather than deterministic GPS radius vector strategy to provide routing alternatives.
The concept of mobile services offers many exciting opportunities. Courtesy of the network coverage created by SONA, asynchronous attachment of mobile devices will be accomplished with certainty throughout the SONA services area.
The local LAN node is constantly scanning whenever it is not being directed to act as a router or is providing meter information. Mobile service nodes can send out a transmission asking for custom assignment to the SONA network. The mobile node would have its own GPS transceiver. Mobile nodes would act as a Quasi-WAN/LAN master, initiating a truncated SONA sequence requesting devices within the target radius to respond to its custom attachment inquiry.
The device is given temporary registration on the network by the coordinating node.
Once the mobile device acquires a network connection it can send and receive data over the network. Upon completion of the transactions the device deregisters from the network. This strategy has enormous implications for wireless credit card verification by delivery people, as a key example.
There is a strong potential for 2.45 GHz or what some are generally calling "Bluetooth" adoption over the next few years. Assuming that there is a need for attached services identified by the owner of the SONA network, LAN nodes could be deployed with Bluetooth modules. There is a great deal of rationale for this practice, both from the standpoint of the cost of the Bluetooth modules as well as the probability of a number of associative services opportunities. Bluetooth will have a maximum range of 100 meters, and manages arbitration between itself and other Bluetooth devices. The LAN module only participates as a network connection when data arrives at the LAN node Bluetooth module that requires network transport for a transaction. Many of these new application devices are being referred to as IP appliances. One of the most logical reasons for a utility to want to consider this option is the fact that many manufacturers are now tamping up to use Bluetooth hardware and protocols as their standard device interface for a wide variety of products. Broad commercial acceptance of a single standard for 2.45 GHz protocol by consumer product manufacturers will make a $5.00 wireless modem a possibility if not a certainty.
Wireless Data Economics There are a lot of data services currently being managed over wired networks, especially large volumes of Internet traffic using TCPIIP protocol. Most data services are being converted to a TCPIIP format to take advantage of the low cost and increased accessibility of Internet transport. For Wireless transport, in the interest of accessibility, Wireless Internet Protocols or Wireless Application Protocol (WAP) as some are calling them have been developed to provide a level of transparency to the Internet transport layer. While simplifying accessibility, a considerable amount of protocol overhead is introduced. WAP
is gaining a lot of attention in media and engineering circles as a panacea for Wireless traffic, but has little value as part of an efficiently structured high volume, small packet Wireless data transport for WAN/LAN strategies. On the Internet, where use is practically free, package efficiency is much less of a consideration.
Optimizing the manner in which data is managed and transported is extremely important to overall Wireless network functionality and wireless economics in general. Inside a WAN/LAN network architecture, especially when the WAN is a public Wireless network, overall efficiency will be an essential component of long-term viability and profitability. This is especially true when the network is packet switched. The LAN portion of the network architecture is also a beneficiary of efficient data management. There are a number of fundamental ways to promote overall data efficiency that enhance both the economics and operational characteristics of the overall network architecture. Typical protocol structures, data structures, and in particular data organization for both WAN and LAN
strategies offer little opportunity to increase the efficiency of AMR data management and transport.
WAN protocols in particular are rigidly defined. The only opportunity for optimization is in the management and organization of the data through the LAN
and at the WAN interface to increase the informational value of data packets that are sent in the protocol wrapper used by the WAN. The difficulties imposed by uniform protocol standards for disparate information requirements, create challenges to the optimization of WAN/LANs for AMR purposes. The even greater challenge is to deliver optimal AMR performance, while also providing an optimal structure for the organization and transport of other value added services information.
AMR Packet Structure and Data Organization Constructing an optimal Packet Structure and Data Organization for AMR
purposes offers a unique opportunity to dramatically increase the efficiency of AMR transactions within WAN/LAN architectures. This will require the use of a different set of organizing theories and principles that more reliably support the real economics of wireless transactions. At the most fundamental level, all wireless transaction economics could be described by this formula:
(Transaction Value) - (Transaction Cost) _ (Transaction Margin) (Where Transaction Value is the Informational value of the transaction and data packet size equates to the Transaction Cost of moving the data over the Public Network.) Conceptually, all transactions can be valued, whether for AMR or any other type of wireless services looking to displace a wired service or to augment a wired service. Given the huge difference in cost between wired and wireless transport, either Transaction Values must increase or Transaction Costs must be reduced to provide an economic rationale for adoption. Of the two scenarios, for virtually any application, the most secure way to drive adoption is to provide a method for reducing cost. I.e. cost displacement. Therefore the most practical method of enhancing Transaction Margin is best pursued through the reduction of Transaction Cost. This can be best described as the formula:
(Information Content) divided by (Data Overhead) _ (Transaction Efficiency) (Where Information Content represents the desired portion of the data package and Data Overhead represents the balance of the data package sent over the network.) A review of Transaction Efficiency across a broad set of Transaction requirements for Wireless Service quickly uncovers opportunities for a dramatic increase in Transaction Efficiency, simply by organizing and structuring the data into two primary categories: Static and Dynamic.
Static Data is the descriptor portion of the data package that describes the Dynamic Data. These descriptors are items such as normal protocol overheads and other associative data that get bundled with Dynamic Data. Examples of Static Data from an AMR context would be Customer ID, Meter ID, LAN ID, WAN ID, Time/Date Stamp, etc.
Dynamic Data is the data that changes over time, and typically represents the portion of any data package that truly represents the informational content of the Transaction. Examples of Dynamic Data from an AMR context would be the meter reading itself. Each LAN device has this Static Data (Customer ID, Meter ID, LAN ID, WAN ID, Time/Date Stamp, etc.) stored in memory. The Static Data is then attached to the Dynamic Data portion (the current meter reading value), and then inserted into a protocol wrapper for transport through the LAN to a WAN
concentrator.
Typical scheduled AMR transactions of this type passed from LAN based meters through WAN concentrators result in packet sizes that range from 60 to 300 bytes depending on packet construction, protocol overhead, etc. Movements of information in packets of this size do not appreciably dilute LAN economics, but rather rely on a reasonable level of LAN performance. However, since a single residential meter reading can be represented in 4 bytes, the efficiencies of these transactions over a WAN are 1.66% (300 bytes) and 6.66% (60 bytes) respectively. Different types of transactions will have wide variations in their Static and Dynamic Data requirements, independent of LAN or WAN protocol overheads, resulting in wide ranging Transaction Efficiencies.
Organizational Structure and Data Packaging for Transaction Efficiency The key to efficient management of transactions over a WAN/LAN network is the precise way in which data is organized and structured at the WAN/LAN
interface.
Certain types of transactions lend themselves well to optimization. In particular, scheduled transactions such as AMR can be repackaged to achieve Transaction Efficiencies of up to 98% in WAN/LAN strategies with LAN to Wan Ratios of 200 to 1 or more. In general, all meter services fall into this scheduled category. This type of packaging also lends itself well to a variety of other Assigned Services while still providing full functionality for Unassigned or Custom Services.
Transaction Services Data Management (TSDM) Assigned Services, such as Scheduled Meter Reading benefit greatly from TSDM. Primary services such as reading utility meters (electric, gas and water meters) require delivery of consumption readings on a predefined schedule.
Custom Services are those transactions that require immediate processing and delivery, such as demand readings for metering, remote alarms, credit card verification, or other transactions that are time/value sensitive that must be managed separately from Assigned Services.
Utility providers and most Commercial Enterprises construct their Enterprise Databases, Billing Systems and Customer Information Systems to Organize a considerable amount of Static Data, such as the Customer's name, phone number, address, Meter ID, etc. Dynamic Data Transactions such as Monthly consumption information, Service charges, Bill payments, etc. are inserted into this structure on an as required basis. Typically these occur once per month for a specific client's billing purposes. The data is organized within a vast table structure that defines the locations for insertion of Dynamic Data values within the Static Table Structure. Every Enterprise organizes and manages their data in this fashion. This structure holds true for Utilities, Banking, and any other Commercial Enterprise.
To insert Dynamic Data into this Static Table Structure, a transfer table must be populated with the Dynamic Data that will load this information in a precise field within the Database. All Transactions, whether managed over wired or wireless mechanisms ultimately must be repackaged in a manner that allows this type of insertion. This activity is managed by a Transaction Server, which collects individual Dynamic Data packages, takes them out of their individual protocol wrappers, and repackages the data into defined fields within the transfer table for insertion into the enterprise's database.
People within the Enterprise can then build queries that allow them to access the precise information they require from the database for their various purposes.
Whether Billing or Customer Services, etc. this is also accomplished through transfer tables constructed to suit the unique requirements of the applications.
The data structure is logically organized to maximize its usefulness for enterprise activities and transfer tables are logically constructed to maximize the insertion and retrieval of information by a wide variety of users.
Assigned Services Table (AST) Structure Today, typical LAN/WAN strategies send individual transactions through the network to a transaction server, where they are repackaged in a transfer file for insertion into the Enterprise Databases. This requires the individual transactions to have enough descriptive Static Data included with the Dynamic Data in the individual transaction data packages to facilitate population and delivery of the appropriate transfer files to the Enterprise Databases. Using an AST that resides at the WAN/LAN interface and a Duplicate of the AST resident at the Transaction Server dramatically reduces Static Data overhead, while still providing all the functionality required for the management of Transaction services, dramatically increasing Transaction Efficiency.
The diagram below depicts a typical Assigned Services Table. (Table 1) LAN GPS Device EM GM WM Assigned Custom Services ID# ID# Data Data Data Services 1 YYYYYY XXXXXXX YES YES NIA NIA Phone-Cut X Detection X
3 YYYYYY XXXXXXX YES YES N/A Demand Security Alarm X
Profiling ... ... ... ... ... ... N/A NIA
239 YYYYYY XXXXXXX YES NIA YES NIA Flood Alarm X
X
LAN ID# = LAN Address assigned by the WANILAN concentrator Device ID# = Unique Address of LAN Device GPS = GPS coordinates of LAN ID
EM = ELECTRIC METER Data GM = GAS METER Data WM = WATER METER Data Assigned Services = Other Assigned Services Data Custom Services = Custom Services Data Having direct knowledge of the table structure at the transaction server level, allows information to be packaged sequentially. Through the table above, it is known which fields are active and populated, the structure and purpose of the information in each field. Each column describes a type of information, and each row describes the information being collected through the individual devices.
When LAN nodes are deployed, they each have a completely unique Device ID.
Once they are attached to a WAN/LAN concentrator, they are assigned a unique LAN Address. Each service, such as Electric, Gas or Water Meter reading, as described in Table 1 is assigned a unique 16-bit Service ID. Every message received from the individual LAN nodes, incorporates the Service ID to identify the type of data being received by the WAN/LAN concentrator for incorporation into the table. In this way over 64,000 individual Assigned Services can be uniquely described. Service ID's describe the unique characteristics of the data in the table field, how the information is packaged, the manner in which it is to be repackaged for transport at the Transaction Server, and its ultimate destination address. Custom Services also use a similar ID assignment. Custom Service data packets are sent directly to the Transaction Server for processing. Each WAN address is a unique 64 Bit address on the network. This WAN address guarantees that the Transaction Server recognizes individual AST's uniquely.
As an example, assuming that 200 LAN nodes are managed per WAN/LAN
concentrator, and assuming 1,000,000 LAN nodes resident within Electric Meters deployed, 5000 WAN/LAN concentrators would be required. (5000 WAN/LAN
concentrators X 200 LAN nodes = 1,000,000) Therefore there would be 5000 unique AST's. The Transaction Server would store a copy of each AST in memory. In Table 1, Assigned LAN ID#'s are stored sequentially 1 -255. The Device ID column and GPS values column identify the unique LAN device and location of the LAN device of the assigned addresses. In each row of the LAN
ID
column, a variable set of services is described, that the LAN ID communicates with locally. All LAN ID's will have an electric meter. Some will have Gas and/or Water meters, while some others will additionally manage other services such as Phone-Cut Line Detection, Flood monitoring, etc.
Structuring the EM Data columnar data as a sequential string of four byte packages can then be used to send all electric Meter readings. This string represents the sequence of addresses 1-XXX with a Service ID header, since the Transaction Server can place these four byte packages back into their table positions into the already known table. In circumstances where the electric meter data is not available for the LAN ID, through the failure of the LAN device, the meter or other difficulties, Null Characters are sent as placeholders to ensure the integrity of the packet sequence. In this way 200, 4 byte meter readings can be sent with approximately 10 bytes of packet overhead over the WAN, achieving Transaction Efficiencies of (800/810) over 98% in comparison to normal efficiencies of 1.5% to 6.6%.
Gas Meter readings are sent in a similar fashion. In the case of GM Data however, there are locations shown in Table 1 that do not have Gas Meters present at indeterminate locations. The table identifies the locations as NlA.
Since there is no data associated with these locations, it is unnecessary to send Null Characters to fill data gaps. The GM Data in the column is strung together sequentially, ignoring the NIA fields in the GM Data table column, putting in Null Characters only when data is missing. In a circumstance where 120 Gas Meters are co-located at LAN ID locations, a sequential string is built of 120, 4byte packets yielding a Transaction Efficiency of over 97%(480/490).
All Assigned Services are assigned columns in the table structure. All packets received by the WAN/LAN concentrator are opened, and have their Service ID
compared to those Service ID's in the table. If the Service ID is the same as one in the table, then the field corresponding to the LAN ID and Service ID is populated with the Dynamic Data in the package. If the Service ID is not contained in the table, then the package is considered to be a Custom Service and is sent to the Transaction Server for processing.
At the Transaction Server, packets received over the Internet are opened.
Each package contains the unique WAN address that allows the transaction server to find the associated AST located in memory. The Transaction Server then compares the Service ID contained in the packet to the Service ID's of the appropriate AST to determine whether the data contained is to be processed as an Assigned Service or Custom Service. If it is for Custom Service, then the information is repackaged in the appropriate Transfer file format and sent to its home location. If the Service ID corresponds to one contained in the AST, then the information is placed in the appropriate column of the AST. Since the Transaction Server knows that the 4 byte packets contained are to be put into the fields in the exact sequence received, it can use the now complete AST
information to build a Transfer files that is/are suitable for insertion at the Enterprise Database locally, or repackage the information for Transport by TCPIIP protocol to anywhere with an Internet connection without significantly altering the Transaction Economics.
reading.
These GPS coordinates, the meter ID, Customer ID and a unique password are placed in a mobile data unit, carried by the installer for subsequent download to a database for verification and later reuse. Essentially, this information lets the utility know where every customer is, the meter type, ID, etc. The WAN/LAN
system can then use this information locally to create what we are now calling a "Self Organizing Network Architecture" (SONA).
SONA Device Descriptions There are essentially two basic types of SONA devices:
~ The LAN node, or Local Area Network transceiver.
~ The WAN/LAN concentrator, which incorporates a WAN transceiver, WAN/LAN interface board and a LAN node.
The LAN node incorporates a 902-928 MHz FHSS radio (or Other Radio/Frequency), with on board microprocessor, flash memory, power supply, and onboard omni directional antenna. For meter applications, either a serial port connection or a pulse counting module is incorporated into the meter prior to installation. Any LAN node can become a WAN/LAN concentrator when a WAN
transceiver and WAN/LAN interface are installed. Any type of WAN connection could be used, and as such is not a key factor in SONA deployment, other than its capacity to manage anticipated WAN transaction requirements. Typical WAN
connections could include Two Way paging, CDPD, GSM, IDEN or RDLAP or the newer Broadband network transceiver modules, as examples.
The single chip CMOS LAN transceiver section (or Other implementation) can be safely operated at power levels between 200 to 300 milliwatts, without incorporating additional amplifier circuitry, depending on overall RF circuit attenuation. The transceiver section of the LAN node can have its power level set through a binary scale of 0 to 255, via the onboard processor, allowing a wide variance in transceiver output.
Every LAN node incorporates sufficient memory to include the Media Access Control layer functions required to effectively act as both a LAN node and a WAN/LAN master. Additional memory is reserved for routing table information, local data storage, parameter storage, as well as any executable code required for local applications management, such as tracking pulses from the meter.
Each LAN module also supports the attachment of Sub-LAN devices/services through a locally managed Sub-LAN addressing strategy. In Sub-LAN service, the local LAN node acts as a master to other co-located LAN devices that negotiate Sub-LAN assignment to the LAN node, which then effectively operates as a Sub-LAN master, routing data through to the WAN.
SONA Registration Management Every device in the deployment, once it gets installed, has its GPS
coordinates loaded into memory via communication with a GPS/LAN module held by the installer or through an IRDA port or other means. WAN/LAN concentrators are distributed in a systematic fashion, consistent with WAN to LAN ratio requirements. i.e., every 200-240 LAN node devices a WAN/LAN concentrator gets implemented. The exact ratio could be any number of devices, but is strongly influenced by the amount of data that needs to be transported by the WAN. This WAN emplacement can, without great difficulty, ensure that WAN
devices are placed evenly within the overall LAN node distribution.
The LAN node address structure uses a single address byte that supports 255 individual addresses, which is incorporated into the protocol packet for transmission. A second address byte incorporated into the protocol packet allows for the attachment of 255 Sub-LAN addresses. Distribution ratios during initial deployment of the network should necessarily contemplate new addresses being assigned over time. The initial ratio of WAN/LAN to LAN devices is best kept between 200 and 240 units depending on average device densities and the potential for higher densities of devices in the future. A number of addresses are reserved for maintenance and supervisory services. Maintaining a consistent set of reserve addresses throughout the domains provides a method for mobile LAN
devices to be used by Utility personnel for local interrogation of meters and other transaction services. This methodology also allows recovery of meter data when a WAN device fails or if the WAN network is unavailable via a LAN transceiver using a reserve address to make a LAN connection anywhere in the network.
Every WAN/LAN concentrator and LAN node starts listening actively once it is installed and GPS located. The GPS coordinates, Device ID, Meter ID and Customer ID as well as a password for access are downloaded into the Network Management System (NMS) from the installers portable units. Every device deployed will only respond to a packet that incorporates the unique LAN ID, password and GPS coordinate of each LAN node or WAN/LAN concentrator.
The NMS incorporates this information into a GPS/GIS oriented database. This database is structured to support an algorithm that organizes LAN nodes that surround each WAN/LAN concentrator into individual domains. The WAN device ID is used to give each domain a unique ID. If a WAN device fails or is changed over to a new network, the domain name changes to the new WAN device ID.
The average domain size is based on the ratio of WAN/LAN concentrators to LAN nodes deployed.
Since the WAN device ID is typically either a unique 32 bit or a 64 bit number, depending on the type of WAN employed, there are virtually an unlimited number of domains that can be created.
At this initial stage, the domain file created is still a theoretical extrapolation, based on the GPS information provided. This file determines the LAN nodes that the WAN/LAN concentrator is expected to capture during its SONA registration sequence to enable effective territory wide SONA network coverage. The NMS
creates a domain file based on this extrapolation and downloads this file to the WAN/LAN concentrator that will operate as the domain master for the LAN nodes nominated by NMS.
The domain file provides the LAN node ID, the GPS coordinate of the LAN node and the password assigned during installation. As part of the domain organization strategy, all of the LAN nodes to be captured are assigned a position in a defined acquisition sequence, based on the relative distance between the WAN/LAN concentrator and the individual nodes. The sequence also contemplates the relative vector angle of the LAN nodes in reference to the WAN/LAN concentrator. This effectively forces a spiral structure to the sequence starting from the LAN node closest to the WAN/LAN concentrator and ending at the most distant.
The WAN/LAN concentrator transmits its first request at a preset power level.
This power level is a theoretical calculation of the transmission power required for secure transmission between the two devices. The power level versus distance algorithm is a preset value, based on the known capabilities of the transceiver. The device meant to receive the packet sends its response at the same power level. Assuming that the bit error rate is acceptable, the WAN/LAN
concentrator then registers the device. Registration of the node, assigns the domain, sets the device status, sets the power level for transmissions, and time synchronizes the device to the network. If the polled device does not respond, then the message is sent again at a higher power level. This methodology guarantees that the lowest practical transmission power is used to arbitrate and register each new LAN node in the sequence. (A more detailed description of Power management is provided later in this document.) Upon receipt of a valid transmission from a polled meter in the sequence, the WAN/LAN concentrator registers the node. During registration, the LAN node is given a unique LAN address that corresponds to its number in the domain polling sequence. The power level needed to establish a secure RF connection and the bit error rate achieved are also written into the table upon registration. A
Received Signal Strength Indication (RSSI) can also be incorporated if available.
Once a LAN node is registered into a WAN/LAN domain, it ignores all transmissions except those registered to that particular domain. The WAN/LAN
concentrator repeats this routine for every LAN node on its domain listing. In most residential applications, low meter densities or local RF path obstructions will not allow the capture of all of the LAN nodes in the domain list during the initial capture sequence. When the full domain list of LAN nodes have been either captured and registered or polled without achieving capture, the WAN/LAN
concentrator sends a file to the NMS comprised of the successfully captured LAN
nodes, the power levels used and the achieved bit error rates.
The NMS places this information into the main database. The power level and achieved bit error rate information is the equivalent of an automated path profile study between the WAN/LAN concentrator and the captured LAN nodes. This data can be used to interpret the local RF environment by the NMS. It can also be used for comparative analysis in the future to determine whether transceiver degradation or RF path degradation is impacting LAN node performance over time.
The NMS then overlays the resulting "path profiles" between the WAN/LAN
concentrator and the individually captured LAN nodes onto the GPS/GIS map area that contains the remaining LAN nodes that were not captured during the initial registration sequence. This information provides a detailed understanding of the local RF environment surrounding the captured devices. This data also provides an excellent statistical probability of the quality of the RF
environment in those areas in the domain where LAN nodes failed to respond in the initial sequence. An algorithm that interprets this information can then select a subset of the captured LAN nodes that have the highest probability to capture the balance of the LAN nodes that were not captured during the initial SONA
sequence.
A new download file is then constructed by the NMS, based on the results of the data interpretation. This file contains the sequence numbers of the LAN nodes chosen to act as LAN node concentrators. A LAN node concentrator acts effectively as a repeater between LAN nodes that failed to register during the primary SONA sequence and the WAN/LAN concentrator. The file also describes the most probable polling path or route to each LAN node that failed to respond during the initial registration sequence. This file is incorporated into a routing table. The routing table describes the proposed path for each LAN node that was not captured during the original polling sequence.
The WAN/LAN concentrator contacts each LAN node selected for use as a LAN
node concentrator and reregisters the LAN node as a LAN concentrator. During the reregistration a file containing a list of LAN node addresses is sent that represent LAN nodes that the concentrator is expected to manage routing for.
Whenever the WAN/LAN concentrator for the domain sends a message for one of these addresses, the LAN concentrator that has received one of these addresses will repeat the message at the power level indicated by the registration packet sent by the WAN/LAN concentrator. The LAN concentrator will repeat any response from the LAN node being contacted, since its address is incorporated in the return packet. The capture strategy employed by the WAN/LAN concentrator during the initial sequence is employed as before, with the only difference being that it factors in the additional delay of the repeater function into its capture strategy. Any LAN nodes captured during the new registration sequence are registered and given their LAN address to the domain as before. Upon completion of the new registration sequence, the power level and bit error rates of the newly acquired LAN nodes are sent to NMS for incorporation into the database and the GPS/GIS path profile map for the domain.
In most circumstances, this secondary capture will complete registration for the domain. In circumstances where this is not the case, the NMS will reinterpret the newly gathered path profile data, and either select newly captured nodes or alternate nodes to be used as LAN concentrators to capture the balance of the missing LAN nodes from the original domain sequence.
The same registration strategy is employed as for the secondary capture, with a key difference being that more than one LAN concentrator will be part of the route. The new LAN node addresses are added to the repeater listing of those LAN nodes that become part of the path. The WAN/LAN concentrator factors in the delay of the additional repeaters in the path, as before.
This process is repeated until all LAN nodes in the domain are captured. At the NMS, supervisory personnel can monitor the progress of the domain registrations. The number of registration sequences employed (or the maximum route length) can be preset by authorized personnel to a preset limit. This allows the propagation of the network within the domain to be monitored by expert supervision. This approach would allow the user to adjust algorithm parameters, based on analysis of gathered path data, adjust power levels used and follow up on situations indicating inoperable or otherwise unavailable devices, to essentially manage network propagation in an optimal manner.
In circumstances where a preferred propagation strategy is required, such as on the edge of WAN coverage, a manually generated domain selection could be sent. Rather than the WAN/LAN concentrator being in the geographic center of the domain, it could be at the edge of the domain, where WAN network coverage exists. This method could also be used to force propagation solely to fill gaps in the SONA coverage, or redefine coverage at a later date.
SONA Transmit Power Management FCC guidelines for 902-928 FHSS radio modems allow a maximum power level of one watt. A key aspect of the SONA strategy is that the LAN node transmits at either a predetermined or programmable power level. Few AMR deployments utilize the full power allowed by the license, due to the additional cost of the transceiver when amplification is required. Also, the general difficulty of managing contention and packet collisions increases in high densities of devices as the transmission power increases. Power output is either based on the theoretical transmission requirements for successful acquisition of the packet by devices within the target distance or a value supplied by NMS based on other influencing characteristics of the RF environment. A power level consistent with the known propagation characteristics and therefore the transmit power requirements for the distance value, might be 1 to 10 milliwatts depending on the attenuation of the device antennae. (Note: A key consideration of FHSS is that unregistered devices must always operate on a default FHSS hopping sequence before final arbitration and registration into a new domain. Once registration is complete, and the appropriate numbers of LAN nodes have been acquired, assigning unique hopping sequences for co-located domains, will reduce local RF collisions and contention. This reassignment is managed through the NMS) The registration packet incorporates the binary power setting of the transmit power used for transmission. If the first attempt does not successfully receive a valid acknowledgement transmission from the LAN node contacted, the WAN/LAN device retransmits at the next staged increment in power level, for example 10 to 100 milliwatts. In the case where a repeater or repeaters are involved, the same case holds true. Any repeaters involved use the previously established power transmit level for retransmission of the packet message. It is important to note that this could mean that it uses different power levels for retransmission depending on the LAN address of the recipient.
Note:
Many ISM band transceiver chip sets also incorporate a RSSI (Received Signal Strength Indication) capability. This information can also be used to dynamically select power level. RSSI looks at the signal power of received transmissions.
Devices could negotiate power levels until minimum signal to noise ratios are achieved. RSSI is also a simple way to identify signal degradation over time, and could be used to have the individual devices manage their own power levels using the RSSI indication as the basis for a transmit power set point.
Missing LAN node Arbitration and Domain Registration In large volume device deployments, it must be expected that some number of devices will exist in or surrounding WAN/LAN concentrator domains that did not acquire domain registration. The domain sequence is then compared to the registration information sent by the WAN/LAN concentrator. The NMS then generates a list of "missing" nodes for supervisory intervention. NMS can also be used to generate alternate routing strategies to acquire missing nodes, by comparing known GPS coordinates of missing devices with known RF paths and vector information of registered LAN and WAN/LAN concentrators. In many circumstances, devices along Domain boundaries may need to be reassigned to a new domain to achieve registration. NMS can also manage redistribution of LAN nodes to balance loading evenly among domains, by reassigning LAN
nodes to co-located domains.
SONA Maintenance Each LAN node now has a known path back to the WAN/LAN concentrators.
When the WAN/LAN concentrator is unable to transmit or receive to any LAN
node due to either a transceiver failure or a reduction in RF path, it notifies the NMS. The NMS in turn, initiates a network repair sequence. The sequence follows a similar pattern to the SONA sequence. In most circumstances, the first repair attempt will simply increase the transmit power of the sending transceiver to see if a response can be achieved. If increasing transmit power does not repair the network connection, then NMS can reroute to another LAN node that represents another probable path/route in the domain. Failure to complete any transaction generates a failure packet, which is sent to a log file and then passed onto the system administrator. NMS can reassign routes automatically or be rerouted manually if required or desirable. NMS manages WAN/LAN
concentrator activity, following up on any failure and generates a service report recommendation for maintenance follow-up.
In the case of a device failure, where replacement is required, SONA
registration is simplified. The new installation information is used to update the database, and the original registration information is used by the WAN/LAN concentrator of the domain to register the newly installed LAN node.
The WAN/LAN concentrator monitors network health during polling, comparing bit error rates of the LAN nodes registered in its domain table to determine certainty of the established routing. Circumstances where transmit power has been increased to ensure network connection, or where rerouting has proven necessary are updated in both the NMS database and the WAN/LAN
concentrator's routing tables as part of routine network management. NMS can initiate a forced domain registration scan on demand where circumstances warrant, such as a natural disaster or in a managed network maintenance strategy.
SONA Sub-LAN Addressing and Registration Sub-LAN devices must also be considered in the overall network strategy. Each LAN node is capable of managing up to 256 devices as an address layer below the SONA LAN node using a single address byte. This second byte is part of all LAN addresses. In circumstances where the LAN node is being polled, the second byte is always represented as 0. Addresses 1 to 255 on the second byte are reserved for Sub-LAN devices. The primary economic rationale for a Sub-LAN address is to support localized associated services at very low transmission levels. Associated services are given a unique assignment ID. The assignment ID limits the protocol overhead required to manage the transactions through the network. A more complete description of the data structure and data management rationale for both LAN and Sub-LAN devices can be found in Appendix "A" attached. This assignment ID also lets NMS know the ultimate destination of data packets, which for this type of information might be a completely different database structure in a different location or Internet address than primary services. The ID also identifies the construction of the packet and the way information is organized within the packet. In this way, the routing of data and the organization, structure and home destinations of the information can be completely separate, yet efficiently defined and managed.
Gas and Water Metering as examples of Sub-LAN Services Since power is best accessed by installation of an electric meter as a "gateway"
device, it is most likely to be the method of entry for a LAN node. The most likely associated services that could be attached to the Electric meter LAN node are other metering activities such as Gas and Water metering. Supplying a source of electric service for power for Gas or Water AMR is extremely cost prohibitive.
Gas and Water metering require an aggressive power conservation strategy to be used to extend battery life. The ultimate strategy is to have battery life be equal to the useful service life of the installed meter. Typically, battery life requires the meter to keep the transceiver section turned off, except during scheduled intervals where meter information is uploaded to a local LAN node for routing to a WAN/LAN node.
Installation of the sub-meter, whether Gas or Water, is performed identically to Electric meter installation, other than the mechanical portion of the installations.
The installation information, including GPS coordinates, LAN ID, meter ID, Customer ID and unique password, is downloaded to the appropriate supervisory system and then subsequently to the NMS database. A Sub-LAN device is sent a message from the NMS via the WAN/LAN concentrator and LAN nodes whose coordinates most closely equate to the GPS location of the Gas or Water meter.
Since data organization and data routing are completely separate, the LAN node next door to the Gas meter could be used rather than the LAN node of the house where the Gas meter was installed. Managing RF efficiency and data integrity is best handled through the closest LAN node.
The NMS generates routing instructions by a review of the existing path profile information. A Sub-LAN Address incorporating the LAN node address of the selected LAN node is generated and sent to the WAN/LAN concentrator. Once the WAN/LAN concentrator has acquired the routing information, it reregisters the LAN node as a Sub-LAN master using a simplified SONA acquisition sequence. The LAN node, acting as a Sub-LAN master then transmits a packet that includes the Gas or Water meter LAN ID and the password. The Sub-LAN
Gas or Water meter is then given its new Sub-LAN address. As part of the registration process, a time date stamp is sent to the meter to schedule activation of its receiver section. The Sub-LAN master node, which also synchronizes itself to the Gas or Water meter LAN node's activation schedule, sends a request for information to the meter at the appointed time. Once the new meter data is received, it sends an acknowledgement packet containing a new time stamp. In this way, time synchronization is maintained between the LAN node and the Sub-LAN node at all times, and transceiver activity is limited to a minimum, extending battery life. This same strategy can be used for any battery powered Sub-LAN
service.
Other Sub-LAN Services There will be two other types of Sub-LAN services. Fixed Sub-LAN services such as phone cut-line detection or load regulation such as A/C, water heating, etc. would be good examples of the first. The second would be the support of mobile transceivers operating as Sub-LAN subscribers. Fixed Sub-LAN services would operate identically to sub metering, except that a power conservation strategy would not be employed. Conceptually, randomly adopted Sub-LAN
services would be difficult to integrate as GPS located nodes. This type of services node would operate within the SONA architecture as a locally assigned and registered device. .To limit overhead and contention this registration would add the service as a Sub-LAN domain participant. NMS will manage this strategy in a similar fashion to standard SONA, using theoretical diversity based on known RF paths and LAN node locations as the grouping strategy rather than deterministic GPS radius vector strategy to provide routing alternatives.
The concept of mobile services offers many exciting opportunities. Courtesy of the network coverage created by SONA, asynchronous attachment of mobile devices will be accomplished with certainty throughout the SONA services area.
The local LAN node is constantly scanning whenever it is not being directed to act as a router or is providing meter information. Mobile service nodes can send out a transmission asking for custom assignment to the SONA network. The mobile node would have its own GPS transceiver. Mobile nodes would act as a Quasi-WAN/LAN master, initiating a truncated SONA sequence requesting devices within the target radius to respond to its custom attachment inquiry.
The device is given temporary registration on the network by the coordinating node.
Once the mobile device acquires a network connection it can send and receive data over the network. Upon completion of the transactions the device deregisters from the network. This strategy has enormous implications for wireless credit card verification by delivery people, as a key example.
There is a strong potential for 2.45 GHz or what some are generally calling "Bluetooth" adoption over the next few years. Assuming that there is a need for attached services identified by the owner of the SONA network, LAN nodes could be deployed with Bluetooth modules. There is a great deal of rationale for this practice, both from the standpoint of the cost of the Bluetooth modules as well as the probability of a number of associative services opportunities. Bluetooth will have a maximum range of 100 meters, and manages arbitration between itself and other Bluetooth devices. The LAN module only participates as a network connection when data arrives at the LAN node Bluetooth module that requires network transport for a transaction. Many of these new application devices are being referred to as IP appliances. One of the most logical reasons for a utility to want to consider this option is the fact that many manufacturers are now tamping up to use Bluetooth hardware and protocols as their standard device interface for a wide variety of products. Broad commercial acceptance of a single standard for 2.45 GHz protocol by consumer product manufacturers will make a $5.00 wireless modem a possibility if not a certainty.
Wireless Data Economics There are a lot of data services currently being managed over wired networks, especially large volumes of Internet traffic using TCPIIP protocol. Most data services are being converted to a TCPIIP format to take advantage of the low cost and increased accessibility of Internet transport. For Wireless transport, in the interest of accessibility, Wireless Internet Protocols or Wireless Application Protocol (WAP) as some are calling them have been developed to provide a level of transparency to the Internet transport layer. While simplifying accessibility, a considerable amount of protocol overhead is introduced. WAP
is gaining a lot of attention in media and engineering circles as a panacea for Wireless traffic, but has little value as part of an efficiently structured high volume, small packet Wireless data transport for WAN/LAN strategies. On the Internet, where use is practically free, package efficiency is much less of a consideration.
Optimizing the manner in which data is managed and transported is extremely important to overall Wireless network functionality and wireless economics in general. Inside a WAN/LAN network architecture, especially when the WAN is a public Wireless network, overall efficiency will be an essential component of long-term viability and profitability. This is especially true when the network is packet switched. The LAN portion of the network architecture is also a beneficiary of efficient data management. There are a number of fundamental ways to promote overall data efficiency that enhance both the economics and operational characteristics of the overall network architecture. Typical protocol structures, data structures, and in particular data organization for both WAN and LAN
strategies offer little opportunity to increase the efficiency of AMR data management and transport.
WAN protocols in particular are rigidly defined. The only opportunity for optimization is in the management and organization of the data through the LAN
and at the WAN interface to increase the informational value of data packets that are sent in the protocol wrapper used by the WAN. The difficulties imposed by uniform protocol standards for disparate information requirements, create challenges to the optimization of WAN/LANs for AMR purposes. The even greater challenge is to deliver optimal AMR performance, while also providing an optimal structure for the organization and transport of other value added services information.
AMR Packet Structure and Data Organization Constructing an optimal Packet Structure and Data Organization for AMR
purposes offers a unique opportunity to dramatically increase the efficiency of AMR transactions within WAN/LAN architectures. This will require the use of a different set of organizing theories and principles that more reliably support the real economics of wireless transactions. At the most fundamental level, all wireless transaction economics could be described by this formula:
(Transaction Value) - (Transaction Cost) _ (Transaction Margin) (Where Transaction Value is the Informational value of the transaction and data packet size equates to the Transaction Cost of moving the data over the Public Network.) Conceptually, all transactions can be valued, whether for AMR or any other type of wireless services looking to displace a wired service or to augment a wired service. Given the huge difference in cost between wired and wireless transport, either Transaction Values must increase or Transaction Costs must be reduced to provide an economic rationale for adoption. Of the two scenarios, for virtually any application, the most secure way to drive adoption is to provide a method for reducing cost. I.e. cost displacement. Therefore the most practical method of enhancing Transaction Margin is best pursued through the reduction of Transaction Cost. This can be best described as the formula:
(Information Content) divided by (Data Overhead) _ (Transaction Efficiency) (Where Information Content represents the desired portion of the data package and Data Overhead represents the balance of the data package sent over the network.) A review of Transaction Efficiency across a broad set of Transaction requirements for Wireless Service quickly uncovers opportunities for a dramatic increase in Transaction Efficiency, simply by organizing and structuring the data into two primary categories: Static and Dynamic.
Static Data is the descriptor portion of the data package that describes the Dynamic Data. These descriptors are items such as normal protocol overheads and other associative data that get bundled with Dynamic Data. Examples of Static Data from an AMR context would be Customer ID, Meter ID, LAN ID, WAN ID, Time/Date Stamp, etc.
Dynamic Data is the data that changes over time, and typically represents the portion of any data package that truly represents the informational content of the Transaction. Examples of Dynamic Data from an AMR context would be the meter reading itself. Each LAN device has this Static Data (Customer ID, Meter ID, LAN ID, WAN ID, Time/Date Stamp, etc.) stored in memory. The Static Data is then attached to the Dynamic Data portion (the current meter reading value), and then inserted into a protocol wrapper for transport through the LAN to a WAN
concentrator.
Typical scheduled AMR transactions of this type passed from LAN based meters through WAN concentrators result in packet sizes that range from 60 to 300 bytes depending on packet construction, protocol overhead, etc. Movements of information in packets of this size do not appreciably dilute LAN economics, but rather rely on a reasonable level of LAN performance. However, since a single residential meter reading can be represented in 4 bytes, the efficiencies of these transactions over a WAN are 1.66% (300 bytes) and 6.66% (60 bytes) respectively. Different types of transactions will have wide variations in their Static and Dynamic Data requirements, independent of LAN or WAN protocol overheads, resulting in wide ranging Transaction Efficiencies.
Organizational Structure and Data Packaging for Transaction Efficiency The key to efficient management of transactions over a WAN/LAN network is the precise way in which data is organized and structured at the WAN/LAN
interface.
Certain types of transactions lend themselves well to optimization. In particular, scheduled transactions such as AMR can be repackaged to achieve Transaction Efficiencies of up to 98% in WAN/LAN strategies with LAN to Wan Ratios of 200 to 1 or more. In general, all meter services fall into this scheduled category. This type of packaging also lends itself well to a variety of other Assigned Services while still providing full functionality for Unassigned or Custom Services.
Transaction Services Data Management (TSDM) Assigned Services, such as Scheduled Meter Reading benefit greatly from TSDM. Primary services such as reading utility meters (electric, gas and water meters) require delivery of consumption readings on a predefined schedule.
Custom Services are those transactions that require immediate processing and delivery, such as demand readings for metering, remote alarms, credit card verification, or other transactions that are time/value sensitive that must be managed separately from Assigned Services.
Utility providers and most Commercial Enterprises construct their Enterprise Databases, Billing Systems and Customer Information Systems to Organize a considerable amount of Static Data, such as the Customer's name, phone number, address, Meter ID, etc. Dynamic Data Transactions such as Monthly consumption information, Service charges, Bill payments, etc. are inserted into this structure on an as required basis. Typically these occur once per month for a specific client's billing purposes. The data is organized within a vast table structure that defines the locations for insertion of Dynamic Data values within the Static Table Structure. Every Enterprise organizes and manages their data in this fashion. This structure holds true for Utilities, Banking, and any other Commercial Enterprise.
To insert Dynamic Data into this Static Table Structure, a transfer table must be populated with the Dynamic Data that will load this information in a precise field within the Database. All Transactions, whether managed over wired or wireless mechanisms ultimately must be repackaged in a manner that allows this type of insertion. This activity is managed by a Transaction Server, which collects individual Dynamic Data packages, takes them out of their individual protocol wrappers, and repackages the data into defined fields within the transfer table for insertion into the enterprise's database.
People within the Enterprise can then build queries that allow them to access the precise information they require from the database for their various purposes.
Whether Billing or Customer Services, etc. this is also accomplished through transfer tables constructed to suit the unique requirements of the applications.
The data structure is logically organized to maximize its usefulness for enterprise activities and transfer tables are logically constructed to maximize the insertion and retrieval of information by a wide variety of users.
Assigned Services Table (AST) Structure Today, typical LAN/WAN strategies send individual transactions through the network to a transaction server, where they are repackaged in a transfer file for insertion into the Enterprise Databases. This requires the individual transactions to have enough descriptive Static Data included with the Dynamic Data in the individual transaction data packages to facilitate population and delivery of the appropriate transfer files to the Enterprise Databases. Using an AST that resides at the WAN/LAN interface and a Duplicate of the AST resident at the Transaction Server dramatically reduces Static Data overhead, while still providing all the functionality required for the management of Transaction services, dramatically increasing Transaction Efficiency.
The diagram below depicts a typical Assigned Services Table. (Table 1) LAN GPS Device EM GM WM Assigned Custom Services ID# ID# Data Data Data Services 1 YYYYYY XXXXXXX YES YES NIA NIA Phone-Cut X Detection X
3 YYYYYY XXXXXXX YES YES N/A Demand Security Alarm X
Profiling ... ... ... ... ... ... N/A NIA
239 YYYYYY XXXXXXX YES NIA YES NIA Flood Alarm X
X
LAN ID# = LAN Address assigned by the WANILAN concentrator Device ID# = Unique Address of LAN Device GPS = GPS coordinates of LAN ID
EM = ELECTRIC METER Data GM = GAS METER Data WM = WATER METER Data Assigned Services = Other Assigned Services Data Custom Services = Custom Services Data Having direct knowledge of the table structure at the transaction server level, allows information to be packaged sequentially. Through the table above, it is known which fields are active and populated, the structure and purpose of the information in each field. Each column describes a type of information, and each row describes the information being collected through the individual devices.
When LAN nodes are deployed, they each have a completely unique Device ID.
Once they are attached to a WAN/LAN concentrator, they are assigned a unique LAN Address. Each service, such as Electric, Gas or Water Meter reading, as described in Table 1 is assigned a unique 16-bit Service ID. Every message received from the individual LAN nodes, incorporates the Service ID to identify the type of data being received by the WAN/LAN concentrator for incorporation into the table. In this way over 64,000 individual Assigned Services can be uniquely described. Service ID's describe the unique characteristics of the data in the table field, how the information is packaged, the manner in which it is to be repackaged for transport at the Transaction Server, and its ultimate destination address. Custom Services also use a similar ID assignment. Custom Service data packets are sent directly to the Transaction Server for processing. Each WAN address is a unique 64 Bit address on the network. This WAN address guarantees that the Transaction Server recognizes individual AST's uniquely.
As an example, assuming that 200 LAN nodes are managed per WAN/LAN
concentrator, and assuming 1,000,000 LAN nodes resident within Electric Meters deployed, 5000 WAN/LAN concentrators would be required. (5000 WAN/LAN
concentrators X 200 LAN nodes = 1,000,000) Therefore there would be 5000 unique AST's. The Transaction Server would store a copy of each AST in memory. In Table 1, Assigned LAN ID#'s are stored sequentially 1 -255. The Device ID column and GPS values column identify the unique LAN device and location of the LAN device of the assigned addresses. In each row of the LAN
ID
column, a variable set of services is described, that the LAN ID communicates with locally. All LAN ID's will have an electric meter. Some will have Gas and/or Water meters, while some others will additionally manage other services such as Phone-Cut Line Detection, Flood monitoring, etc.
Structuring the EM Data columnar data as a sequential string of four byte packages can then be used to send all electric Meter readings. This string represents the sequence of addresses 1-XXX with a Service ID header, since the Transaction Server can place these four byte packages back into their table positions into the already known table. In circumstances where the electric meter data is not available for the LAN ID, through the failure of the LAN device, the meter or other difficulties, Null Characters are sent as placeholders to ensure the integrity of the packet sequence. In this way 200, 4 byte meter readings can be sent with approximately 10 bytes of packet overhead over the WAN, achieving Transaction Efficiencies of (800/810) over 98% in comparison to normal efficiencies of 1.5% to 6.6%.
Gas Meter readings are sent in a similar fashion. In the case of GM Data however, there are locations shown in Table 1 that do not have Gas Meters present at indeterminate locations. The table identifies the locations as NlA.
Since there is no data associated with these locations, it is unnecessary to send Null Characters to fill data gaps. The GM Data in the column is strung together sequentially, ignoring the NIA fields in the GM Data table column, putting in Null Characters only when data is missing. In a circumstance where 120 Gas Meters are co-located at LAN ID locations, a sequential string is built of 120, 4byte packets yielding a Transaction Efficiency of over 97%(480/490).
All Assigned Services are assigned columns in the table structure. All packets received by the WAN/LAN concentrator are opened, and have their Service ID
compared to those Service ID's in the table. If the Service ID is the same as one in the table, then the field corresponding to the LAN ID and Service ID is populated with the Dynamic Data in the package. If the Service ID is not contained in the table, then the package is considered to be a Custom Service and is sent to the Transaction Server for processing.
At the Transaction Server, packets received over the Internet are opened.
Each package contains the unique WAN address that allows the transaction server to find the associated AST located in memory. The Transaction Server then compares the Service ID contained in the packet to the Service ID's of the appropriate AST to determine whether the data contained is to be processed as an Assigned Service or Custom Service. If it is for Custom Service, then the information is repackaged in the appropriate Transfer file format and sent to its home location. If the Service ID corresponds to one contained in the AST, then the information is placed in the appropriate column of the AST. Since the Transaction Server knows that the 4 byte packets contained are to be put into the fields in the exact sequence received, it can use the now complete AST
information to build a Transfer files that is/are suitable for insertion at the Enterprise Database locally, or repackage the information for Transport by TCPIIP protocol to anywhere with an Internet connection without significantly altering the Transaction Economics.
Claims (11)
1. A method for forming a routing table for an automated meter reading system in which a plurality of meters are assigned to a primary concentrator that in turn forms part of a wide area network for transmitting data collected from the meters to a central location for further processing, the method comprising:
for each meter assigned to the primary concentrator, attempting to transmit data from the primary concentrator to the meter, starting at an initial signal strength and increasing the signal strength until the data is transmitted successfully to the meter or the signal strength can be increased no further, and if the data was successfully transmitted to the meter, registering the meter in the routing table with an indication that direct transmission between the primary concentrator and the meter is possible;
and then for any meter remaining unregistered, selecting a registered meter from a list of possible secondary concentrators comprised of those meters registered in the routing table with an indication that direct transmission between the primary concentrator and the meter is possible, attempting to transmit data from the selected registered meter to the unregistered meter, starting at an initial signal strength and increasing the signal strength until the data is transmitted successfully or the signal strength can be increased no further, if data cannot be transmitted to the unregistered meter by the selected registered meter, continuing to select registered meters from the list of possible secondary concentrators and attempt to transmit data until a registered meter is found that can transmit data to the unregistered meter or until all such registered meters on the list of possible secondary concentrators have been tried, and if data was successfully transmitted to the unregistered meter by the selected registered meter, registering the previously unregistered meter in the routing table with an indication that transmission between the primary concentrator and the previously unregistered meter is possible by using the selected registered meter as a secondary concentrator.
for each meter assigned to the primary concentrator, attempting to transmit data from the primary concentrator to the meter, starting at an initial signal strength and increasing the signal strength until the data is transmitted successfully to the meter or the signal strength can be increased no further, and if the data was successfully transmitted to the meter, registering the meter in the routing table with an indication that direct transmission between the primary concentrator and the meter is possible;
and then for any meter remaining unregistered, selecting a registered meter from a list of possible secondary concentrators comprised of those meters registered in the routing table with an indication that direct transmission between the primary concentrator and the meter is possible, attempting to transmit data from the selected registered meter to the unregistered meter, starting at an initial signal strength and increasing the signal strength until the data is transmitted successfully or the signal strength can be increased no further, if data cannot be transmitted to the unregistered meter by the selected registered meter, continuing to select registered meters from the list of possible secondary concentrators and attempt to transmit data until a registered meter is found that can transmit data to the unregistered meter or until all such registered meters on the list of possible secondary concentrators have been tried, and if data was successfully transmitted to the unregistered meter by the selected registered meter, registering the previously unregistered meter in the routing table with an indication that transmission between the primary concentrator and the previously unregistered meter is possible by using the selected registered meter as a secondary concentrator.
2. The method of claim 1, wherein data is transmitted between the primary concentrator and the meters and among the meters by radio frequency transmissions.
3. The method of claim 2, wherein registered meters are selected from the list of possible secondary concentrators in order of increasing distance from the unregistered meter.
4. The method of claim 3, wherein the list of possible secondary concentrators contains all previously registered meters for which direct transmission with the primary concentrator is possible.
5. The method of claim 3 or claim 4, wherein GPS coordinates of the primary concentrator and the meters are used to calculate distances.
6. The method of claim 3, wherein the list of possible secondary concentrators contains all previously registered meters for which direct transmission with the primary concentrator is possible other than those previously registered meters that are on or near a radio frequency path extending from the primary concentrator to the unregistered meter.
7. The method of claim 6, wherein GPS coordinates of the primary concentrator and the meters are used to calculate distances and proximity to a radio frequency path.
8. The method of claim 3, wherein the initial signal strength at which data is transmitted from the primary concentrator is the minimum signal strength at which data can be transmitted from the primary concentrator and the initial signal strength at which data is transmitted from the secondary concentrator is the minimum signal strength at which data can be transmitted from the secondary concentrator, thereby to minimize interference with adjacent radio frequency devices.
9. The method of claim 3, wherein the initial signal strength at which data is transmitted from the primary concentrator is calculated as the minimum theoretical signal strength needed to cover the distance from the primary concentrator to the unregistered meter and the initial signal strength at which data is transmitted from a possible secondary concentrator is calculated as the minimum theoretical signal strength needed to cover the distance from the possible secondary concentrator to the unregistered meter, thereby to minimize interference with adjacent radio frequency devices.
10. The method of claim 9, wherein GPS coordinates of the primary concentrator and the meters are used to calculate distances.
11. The method of any of the preceding claims, wherein each transmission to a meter from the primary concentrator or any previously registered meter contains data representing the signal strength to be used by the meter receiving the transmission to respond to the transmission, the signal strength to be used to respond being equal to the signal strength at which the primary concentrator or previously registered meter transmitted the transmission.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002308819A CA2308819A1 (en) | 2000-05-15 | 2000-05-15 | Self organizing network architecture |
| PCT/CA2001/000691 WO2001087279A2 (en) | 2000-05-15 | 2001-05-15 | Self-organizing network architecture |
| AU2001259981A AU2001259981A1 (en) | 2000-05-15 | 2001-05-15 | Self-organizing network architecture |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002308819A CA2308819A1 (en) | 2000-05-15 | 2000-05-15 | Self organizing network architecture |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2308819A1 true CA2308819A1 (en) | 2001-11-15 |
Family
ID=4166179
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002308819A Abandoned CA2308819A1 (en) | 2000-05-15 | 2000-05-15 | Self organizing network architecture |
Country Status (3)
| Country | Link |
|---|---|
| AU (1) | AU2001259981A1 (en) |
| CA (1) | CA2308819A1 (en) |
| WO (1) | WO2001087279A2 (en) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7061398B2 (en) * | 1999-08-16 | 2006-06-13 | Bs&B Safety Systems Limited | Two-way wide area telemetry |
| DE102004062157B4 (en) | 2004-12-20 | 2007-12-20 | EMH Elektrizitätszähler GmbH & Co. KG | Device for detecting counter readings |
| US8311543B2 (en) | 2005-07-07 | 2012-11-13 | Qualcomm Incorporated | Methods and devices for interworking of wireless wide area networks and wireless local area networks or wireless personal area networks |
| US8364148B2 (en) | 2005-07-07 | 2013-01-29 | Qualcomm Incorporated | Methods and devices for interworking of wireless wide area networks and wireless local area networks or wireless personal area networks |
| US9078099B2 (en) | 2012-07-16 | 2015-07-07 | Qualcomm Incorporated | Localization method employing radio signal strength measurements of electric and gas meters |
| CN105046928B (en) * | 2015-06-25 | 2018-08-24 | 江苏林洋能源股份有限公司 | A kind of method of Auto-Sensing and management meter archives |
| CN106935008B (en) * | 2015-12-29 | 2020-08-07 | 深圳长城开发科技股份有限公司 | Ad hoc network method of meter reading system |
| CN107369309B (en) * | 2017-07-14 | 2019-07-16 | 国网浙江省电力公司 | A kind of water for half-duplex channel, air and heat meter actively perceive method |
| CN114627633A (en) * | 2020-12-12 | 2022-06-14 | 福建江夏学院 | Ad hoc network water meter centralized reading system and method constructed based on multiple agents |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4864563A (en) * | 1989-01-09 | 1989-09-05 | E-Systems, Inc. | Method for establishing and maintaining a nodal network in a communication system |
| CA2129199C (en) * | 1994-07-29 | 1999-07-20 | Roger Y.M. Cheung | Method and apparatus for bridging wireless lan to a wired lan |
| US5737318A (en) * | 1995-12-27 | 1998-04-07 | Philips Electronics North America Corporation | Method for initializing a wireless, packet-hopping network |
| US6073169A (en) * | 1997-04-08 | 2000-06-06 | Abb Power T&D Company Inc. | Automatic meter reading system employing common broadcast command channel |
| GB9919920D0 (en) * | 1999-08-24 | 1999-10-27 | Cedardell Ltd | Apparatus and method for wireless communication |
-
2000
- 2000-05-15 CA CA002308819A patent/CA2308819A1/en not_active Abandoned
-
2001
- 2001-05-15 AU AU2001259981A patent/AU2001259981A1/en not_active Abandoned
- 2001-05-15 WO PCT/CA2001/000691 patent/WO2001087279A2/en active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| AU2001259981A1 (en) | 2001-11-26 |
| WO2001087279A3 (en) | 2004-02-26 |
| WO2001087279A2 (en) | 2001-11-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Hubaux et al. | Toward self-organized mobile ad hoc networks: The Terminodes Project | |
| US8855019B2 (en) | Wireless communication enabled meter and network | |
| CN100508489C (en) | System and method for dynamic interface management | |
| US8000314B2 (en) | Wireless network system and method for providing same | |
| US7436789B2 (en) | Ad Hoc wireless node and network | |
| CN102457933B (en) | Wireless network device, wireless network system and routing control method | |
| US20120166610A1 (en) | Method and system for communication in application field | |
| JP2007535203A (en) | Wireless communication method and apparatus in mesh network | |
| CA2308819A1 (en) | Self organizing network architecture | |
| Ilchev et al. | Internet-of-Things communication protocol for low-cost devices in heterogeneous wireless networks | |
| CN102196529A (en) | Access method and system for wireless sensor network | |
| Kanthavel et al. | Multi‐hoped cooperative communication‐based wireless underground sensor network design | |
| Pang et al. | A UHF RFID-based system for children tracking | |
| Poor | Hyphos--a self-organizing, wireless network | |
| Heeger et al. | Secure energy constrained LoRa mesh network | |
| Novelli et al. | Application protocols and wireless communication for IoT: a simulation case study proposal | |
| Mohamed et al. | IoT networking and communication layer | |
| CN102300206A (en) | Addressing method of wireless sensor network (WSN) terminal and combination network | |
| US20230058016A1 (en) | Iot multicast out-of-band cybersecurity messaging system and method | |
| Maala et al. | HERO: Hierarchical kEy management pRotocol for heterOgeneous wireless sensor networks | |
| Bhattacharya | Randomized location service in mobile ad hoc networks | |
| EP1686735B1 (en) | Information transmission network | |
| Bhuvaneswari | A Survey on Internet of Things [IoT]. | |
| CN102202376A (en) | Joining network and method for joining wireless sensor network (WSN) terminal in network | |
| Asadollahseraj | Design of Low Power Gateways for LoRaWAN Applications In Remote Areas |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |