Using the Internet to send and receive meter data is a topic of discussion at many utilities. A number of proprietary protocols are available today, but soon, a new ANSI standard protocol will be published to cover this application. This article describes the new protocol, including its impact on both Internet and radio networks.
Imagine that you’re surfing the web and you see a web link that looks interesting to you. If you’re like most people, you probably don’t think about how that mouse click results in displaying the requested web page. When you click on a link with the mouse, the web browser issues a Hypertext Transfer Protocol (HTTP) GET request for that specific page. This request makes its way through the Internet network to a web server, which could be anywhere in the world. In response, the web server delivers the web page content through the Internet network to the web browser, which displays the web page. Regardless of how your computer is connected to the web, through a modem dial-up connection or an Ethernet connection to a local area network (LAN), the request issued by the web browser is the same.
This characteristic of Internet network design has significant advantages over other possible designs. One advantage is that only one web browser is needed that sits on top of the underlying transport protocols (for example, TCP/IP over PPP over dial-up, or TCP/IP over Ethernet). This design characteristic also helps the programmers who develop the applications that make the Internet work. The browser programmers can concentrate on browser functions without having to worry about underlying protocols, and the protocol developers can do their job without needing to know what applications are using the protocol.
To explain this characteristic of Internet network design in simple terms, consider this analogy. If you send a letter to Moscow by traditional post, you are the application writing the letter and the postal carrier is implementing the underlying transport protocol. You don’t need to know any of the details of how the Russian postal system works, and the letter carrier doesn’t need to know the contents of your letter.
ANSI C12.22 is the designation of a new standard that is being developed to allow the transport of ANSI C12.19 table data over networked connections. It is part of a group of related ANSI protocols but has some fundamental differences from the other protocols within the group. This article discusses the ANSI C12.22 protocol and how it works, but to fully understand the C12.22 protocol, it is helpful to consider a brief history of ANSI meter communications standards.
A Brief History of ANSI Meter Communications Standards
Years ago, data formats, data structures and communications protocols for electricity meters were all proprietary. But, utility companies wanted a compatible communication protocol between ANSI meters so they were not restricted to a single electricity meter vendor. To meet this requirement, ANSI standards were created that describe meter data formats and structures (C12.19), and provide a simple optical point-topoint communications protocol (C12.18) that allowed them to communicate with ANSI standard meters.
While this was a huge step forward in making a standard communication protocol for electricity meters, it wasn’t long before users wanted to be able to send and receive ANSI tables remotely. To address that need, C12.18 was adapted to create C12.21. ANSI Standard C12.21-1999 specified a new version of C12.18 that was modified for telephone modems. This protocol was still strictly point-to-point communication and session oriented. Minor modifications were made to account for longer communication timeouts and for security since it could no longer be assumed that a person would be standing directly in front of the meter.
How and Why is C12.22 Different?
C12.18 described every detail of the physical attributes for optical communication ports (dimensions, LED wavelength, etc.). This standard was needed to build meters with a compatible communication interface. When C12.21 was created to implement point-to-point communication between meters, the intent was to use it with already existing modems. For this ANSI communication standard it did not make any sense for the ANSI subcommittee to describe particular modulation techniques and the physical connector used in modems because these aspects were already specified by other standards.
Although C12.21 is a meter communications standard and not a modem standard, some general attributes regarding modems were incorporated into the C12.21 standard. For example, initialization and dial strings were specified, but connector specification and electrical characteristics were not. The format and structure of the communications packets that carry C12.21 requests and responses are described in detail in the standard, but below a certain point, the detail stops. In the language of communications standards, the C12.21 protocol is more abstract than C12.18 because it deliberately omits the lower layer details. C12.22 is different from C12.21 in the same way that C12.21 is different from C12.18. C12.22 is more abstract because it omits even more of the underlying protocol details. The reason for these differences is also related. C12.22 is intended for use over already existing communication networks just as C12.21 is intended to for use with already existing modems. Examples of such communication networks covered by C12.22 include TCP/IP over Ethernet, SMS over GSM, or UDP/IP over PPP over serial port. Just as HTTP provides a common application layer that all web browsers can use, C12.22 provides a common application layer that all meters can use.
OSI Reference Model
The ISO (International Organization for Standardization) OSI (Open Systems Interconnections) is a set of international standards that describe how computer systems may be interconnected to support the exchange of information in a consistent fashion. It is commonly referred to as the OSI Reference Model, or the "seven layer model." It provides a standard for layering communication protocols, which makes it easier to understand and implement in product design.
Seven Layer Model
While many people are familiar with the OSI Reference Model, Figure 1 provides an overview of the communication protocols contained in each layer.
Layer 7 - Application
The Application Layer describes network applications from the user’s point of view. It includes things like HTTP, File Transport Protocol (FTP), and email protocols. ANSI table reads and writes belong to this layer.
Layer 6 - Presentation
The Presentation Layer describes the syntax of data being transferred, and formats and unwraps the data for application layer processing. Data encryption, data compression and protocol translations would be in this layer.
Layer 5 - Session
The Session Layer describes the organization of data sequences larger than the packets handled by lower layers. An example of this is a single request for load profile data that is handled by multiple packets containing the actual load profile log data.
Layer 4 - Transport
The Transport Layer describes the quality and nature of the data delivery. This layer is responsible for data reliability and integrity. If the underlying network layer fails to deliver a packet, it is the transport layer that issues a request for retransmission. This layer is also the lowest one at which an end-to-end connection exists.
Layer 3 - Network
The Network Layer describes how a series of exchanges over various data links can deliver data between any two nodes in a network. Routing and forwarding, addressing, congestion control and packet sequencing are functions of this layer.
Layer 2 - Data Link
The Data Link Layer describes the logical organization of data bits transmitted on a particular medium. The calculation of packet Cyclic Redundancy Codes (CRC) in C12.18 and handling of packet level ACK and NAK responses are examples of Data Link Layer functions.
Layer 1 - Physical
The Physical Layer describes the physical properties of the various communications media, and the encoding of information on the physical media. An example from C12.18 would be light levels, wavelengths, and physical dimensions of the optical port.
C12.22 Scope
The scope of work for C12.22 was defined early in the process to explain the document and to serve as a guide to help the committee members stay on track.One key point is that there are two different models of implementation addressed by the standard:
The model for meters with an integrated network connection only specifies the application layer protocol. It may implement any kind of lower layer protocols.
The model for meters with a separate CM has the meter on one side and the target network on the other side of the CM. The interface between the CM and the meter is explicitly and completely defined down to the physical layer (Layer 1). The interface on the network side of the CM is only defined at the application layer (Layer 7) since the underlying network is not dictated by the standard. This allows for communication modules to be interchangeable without dictating the network on which the module is used.
Unlike C12.18 or C12.21 that only provide session-oriented communications, C12.22 provides for both session and sessionless communications. In a session, both ends keep track of what they have done so far in the connection. For example, after providing a password, subsequent read requests are granted or denied based on that password. In sessionless communications, neither side needs to keep this kind of information because each transaction is independent of the previous ones. In a sessionless communication, for example, a read request also includes the encrypted password. Sessionless communication has the advantage of requiring less complex handling on both sides of the communication link and fewer packets exchanged if communications sessions tend to be short.
C12.22 Application Layer Services
C12.22 also describes a number of Application Layer Services. All of the functions of the C12.22 protocol are handled through combinations of these services. The Application Layer Services provided in C12.22 are:
Identification request (ident)
Like the identification request of C12.18 or C12.21, this identification request allows the meter to send basic protocol identification, including which protocol is being used and a feature list that includes things like encryption parameters in C12.21. Added to C12.22 are session control information and the ability to indicate compression support. Encryption parameters were generalized to become security mechanism.
Read request (read)
Identical to a read request in C12.18, this service allows reading a full table, a partial table or the curiously undefined “default table.”
Write request (write)
Identical to a write request in C12.18, this service allows writing a full table or a partial table.
Logon request (logon)
Identical to a logon request in C12.18, this service establishes a session without establishing access permissions.
Security request (security)
Identical to a security request in C12.18, this service establishes access permissions by a simple unencrypted password.
Logoff request (logoff)
Identical to a logoff request in C12.18, this service provides for an orderly shutdown of the session established by the logon service.
Wait request (wait)
Wait request is used to maintain an established connection during idle periods to avoid automatic termination from a traffic timeout.
Registration request (register)
Registration request is used to add and maintain routing tables of C12.22 relays. This is covered later in the description of routing.
De-registration request (de-register)
De-registration request is used to remove a routing table entry of a C12.22 relay. This is also covered later in the description of routing.
Resolve request (resolve)
Resolve request is used to retrieve the native network address of the C12.22 node. This native address can be used to communicate with other nodes on the same network segment.
Trace request (trace)
Trace request is used to get a list of relays capable of forwarding messages to a target node. This is intended mostly for diagnostics.
The Impact of C12.22 on Internet Metering
There are alternative methods to C12.22 by which meter data is transported over a network. Instead of wrapping C12.18 or C12.21 protocol transactions in an existing network transport protocol such as TCP, the committee decided to use C12.22 for three main reasons: improved security, reliability, and speed.
Improved Security
The first reason is improved security. In C12.18 the password is sent unencrypted. This is not a problem for a point-to-point connection from a handheld device to an optical port on a meter, but when data is transmitted over the Internet, it’s a serious security problem. A hacker with a computer loaded with freely available packet sniffing software can look at the packet and see the password. C12.21 has an alternative authentication mechanism, which provides for encrypted authentication, but the encryption is only used for authentication and all subsequent data reads and writes are done unencrypted. With a point-topoint connection via dialup telephone lines, this is not a problem because intercepting such communications is very difficult, but if the data is transmitted over the Internet, we once again have a problem because hackers can easily intercept the data. In both of these cases, the problem created is that a hacker, having successfully monitored the login, can now freely interfere with the meter and the automated meter reading (AMR) system. C12.22 enables data encryption without requiring it, so no additional communications resources are used until encryption is actually used.
Reliability
Reliability is the second reason C12.22 is preferred over wrapping C12.18 transactions in TCP. Remember that C12.18 was intended for use over a point-to-point connection via an optical connection with very low error rates. In a typical network, errors and retransmissions are common and the data frames may arrive out of sequence. You might get the second half of the message before you get the first half. TCP takes care of these details and hides their effect to a point, but there is a cost. First, every TCP connection requires a three-way handshake to open the connection. Then, every application layer request that gets transmitted over TCP must be delivered completely before it is passed to the receiving point application layer. If the second half of the message arrives first, it is not available to the application layer until the first half also arrives. This is a useful property of the TCP transport service, but it has consequences. C12.18 and C12.21 both say that if an expected reply is not received before the traffic timeout period expires; the request should be retransmitted. If this happens, then the second response is also blocked until the first transmission is satisfied (by receiving the missing first half of the message) or the session times out at the TCP layer.
Speed
The third reason is speed. C12.22 provides for messages that do not require a session. This means a single transaction (see Figure 2) can support an authentication and read billing data request without the usual overhead of a table read transaction (see Figure 3). It’s important to note that this applies whether or not the data is transmitted over any Internet segments. Because of this overhead, a radio network built using C12.21 or C12.18 may be more expensive to operate because radio networks are often billed by the amount of airtime used.
Conclusion
The utility industry trend is to read increasing numbers of meters remotely using various types of networks. As communications options diversify, some kind of packet-based network is more frequently used for this purpose. The C12.22 standard accommodates this diversity without becoming a nightmare for manufacturers, utilities, and regulators. This article covered just a few of the many facets of C12.22. If you would like to learn more, the entire draft standard is available on the web at: www.nertec.com/standards/ansic1222/index.htm and also at www.forums.nema.org/~ansi_c12-17. Our meetings are open, and we welcome your participation and comments.
About the Author
Edward Beroset has been working with computers and software for over 20 years. Edward is the manager of the software and test group at Elster Electricity, where he has worked for seven years. Prior to that, he worked in BIOS development at Compaq. He serves on IEC and ANSI electricity metering protocol standards groups and chairs the working group which is responsible for creating the C12.22 standard. He is a member of both the IEEE and the ACM, has published several articles and holds several US and foreign patents.
Imagine that you’re surfing the web and you see a web link that looks interesting to you. If you’re like most people, you probably don’t think about how that mouse click results in displaying the requested web page. When you click on a link with the mouse, the web browser issues a Hypertext Transfer Protocol (HTTP) GET request for that specific page. This request makes its way through the Internet network to a web server, which could be anywhere in the world. In response, the web server delivers the web page content through the Internet network to the web browser, which displays the web page. Regardless of how your computer is connected to the web, through a modem dial-up connection or an Ethernet connection to a local area network (LAN), the request issued by the web browser is the same.
This characteristic of Internet network design has significant advantages over other possible designs. One advantage is that only one web browser is needed that sits on top of the underlying transport protocols (for example, TCP/IP over PPP over dial-up, or TCP/IP over Ethernet). This design characteristic also helps the programmers who develop the applications that make the Internet work. The browser programmers can concentrate on browser functions without having to worry about underlying protocols, and the protocol developers can do their job without needing to know what applications are using the protocol.
To explain this characteristic of Internet network design in simple terms, consider this analogy. If you send a letter to Moscow by traditional post, you are the application writing the letter and the postal carrier is implementing the underlying transport protocol. You don’t need to know any of the details of how the Russian postal system works, and the letter carrier doesn’t need to know the contents of your letter.
ANSI C12.22 is the designation of a new standard that is being developed to allow the transport of ANSI C12.19 table data over networked connections. It is part of a group of related ANSI protocols but has some fundamental differences from the other protocols within the group. This article discusses the ANSI C12.22 protocol and how it works, but to fully understand the C12.22 protocol, it is helpful to consider a brief history of ANSI meter communications standards.
A Brief History of ANSI Meter Communications Standards
Years ago, data formats, data structures and communications protocols for electricity meters were all proprietary. But, utility companies wanted a compatible communication protocol between ANSI meters so they were not restricted to a single electricity meter vendor. To meet this requirement, ANSI standards were created that describe meter data formats and structures (C12.19), and provide a simple optical point-topoint communications protocol (C12.18) that allowed them to communicate with ANSI standard meters.
While this was a huge step forward in making a standard communication protocol for electricity meters, it wasn’t long before users wanted to be able to send and receive ANSI tables remotely. To address that need, C12.18 was adapted to create C12.21. ANSI Standard C12.21-1999 specified a new version of C12.18 that was modified for telephone modems. This protocol was still strictly point-to-point communication and session oriented. Minor modifications were made to account for longer communication timeouts and for security since it could no longer be assumed that a person would be standing directly in front of the meter.
How and Why is C12.22 Different?
C12.18 described every detail of the physical attributes for optical communication ports (dimensions, LED wavelength, etc.). This standard was needed to build meters with a compatible communication interface. When C12.21 was created to implement point-to-point communication between meters, the intent was to use it with already existing modems. For this ANSI communication standard it did not make any sense for the ANSI subcommittee to describe particular modulation techniques and the physical connector used in modems because these aspects were already specified by other standards.
Although C12.21 is a meter communications standard and not a modem standard, some general attributes regarding modems were incorporated into the C12.21 standard. For example, initialization and dial strings were specified, but connector specification and electrical characteristics were not. The format and structure of the communications packets that carry C12.21 requests and responses are described in detail in the standard, but below a certain point, the detail stops. In the language of communications standards, the C12.21 protocol is more abstract than C12.18 because it deliberately omits the lower layer details. C12.22 is different from C12.21 in the same way that C12.21 is different from C12.18. C12.22 is more abstract because it omits even more of the underlying protocol details. The reason for these differences is also related. C12.22 is intended for use over already existing communication networks just as C12.21 is intended to for use with already existing modems. Examples of such communication networks covered by C12.22 include TCP/IP over Ethernet, SMS over GSM, or UDP/IP over PPP over serial port. Just as HTTP provides a common application layer that all web browsers can use, C12.22 provides a common application layer that all meters can use.
OSI Reference Model
The ISO (International Organization for Standardization) OSI (Open Systems Interconnections) is a set of international standards that describe how computer systems may be interconnected to support the exchange of information in a consistent fashion. It is commonly referred to as the OSI Reference Model, or the "seven layer model." It provides a standard for layering communication protocols, which makes it easier to understand and implement in product design.
Seven Layer Model
While many people are familiar with the OSI Reference Model, Figure 1 provides an overview of the communication protocols contained in each layer.
Figure 1
Layer 7 - Application
The Application Layer describes network applications from the user’s point of view. It includes things like HTTP, File Transport Protocol (FTP), and email protocols. ANSI table reads and writes belong to this layer.
Layer 6 - Presentation
The Presentation Layer describes the syntax of data being transferred, and formats and unwraps the data for application layer processing. Data encryption, data compression and protocol translations would be in this layer.
Layer 5 - Session
The Session Layer describes the organization of data sequences larger than the packets handled by lower layers. An example of this is a single request for load profile data that is handled by multiple packets containing the actual load profile log data.
Layer 4 - Transport
The Transport Layer describes the quality and nature of the data delivery. This layer is responsible for data reliability and integrity. If the underlying network layer fails to deliver a packet, it is the transport layer that issues a request for retransmission. This layer is also the lowest one at which an end-to-end connection exists.
Layer 3 - Network
The Network Layer describes how a series of exchanges over various data links can deliver data between any two nodes in a network. Routing and forwarding, addressing, congestion control and packet sequencing are functions of this layer.
Layer 2 - Data Link
The Data Link Layer describes the logical organization of data bits transmitted on a particular medium. The calculation of packet Cyclic Redundancy Codes (CRC) in C12.18 and handling of packet level ACK and NAK responses are examples of Data Link Layer functions.
Layer 1 - Physical
The Physical Layer describes the physical properties of the various communications media, and the encoding of information on the physical media. An example from C12.18 would be light levels, wavelengths, and physical dimensions of the optical port.
C12.22 Scope
The scope of work for C12.22 was defined early in the process to explain the document and to serve as a guide to help the committee members stay on track.One key point is that there are two different models of implementation addressed by the standard:
- Meters with an integrated network connection
- Meters with a separate communications module (CM)
The model for meters with an integrated network connection only specifies the application layer protocol. It may implement any kind of lower layer protocols.
The model for meters with a separate CM has the meter on one side and the target network on the other side of the CM. The interface between the CM and the meter is explicitly and completely defined down to the physical layer (Layer 1). The interface on the network side of the CM is only defined at the application layer (Layer 7) since the underlying network is not dictated by the standard. This allows for communication modules to be interchangeable without dictating the network on which the module is used.
Unlike C12.18 or C12.21 that only provide session-oriented communications, C12.22 provides for both session and sessionless communications. In a session, both ends keep track of what they have done so far in the connection. For example, after providing a password, subsequent read requests are granted or denied based on that password. In sessionless communications, neither side needs to keep this kind of information because each transaction is independent of the previous ones. In a sessionless communication, for example, a read request also includes the encrypted password. Sessionless communication has the advantage of requiring less complex handling on both sides of the communication link and fewer packets exchanged if communications sessions tend to be short.
C12.22 Application Layer Services
C12.22 also describes a number of Application Layer Services. All of the functions of the C12.22 protocol are handled through combinations of these services. The Application Layer Services provided in C12.22 are:
Identification request (ident)
Like the identification request of C12.18 or C12.21, this identification request allows the meter to send basic protocol identification, including which protocol is being used and a feature list that includes things like encryption parameters in C12.21. Added to C12.22 are session control information and the ability to indicate compression support. Encryption parameters were generalized to become security mechanism.
Read request (read)
Identical to a read request in C12.18, this service allows reading a full table, a partial table or the curiously undefined “default table.”
Write request (write)
Identical to a write request in C12.18, this service allows writing a full table or a partial table.
Logon request (logon)
Identical to a logon request in C12.18, this service establishes a session without establishing access permissions.
Security request (security)
Identical to a security request in C12.18, this service establishes access permissions by a simple unencrypted password.
Logoff request (logoff)
Identical to a logoff request in C12.18, this service provides for an orderly shutdown of the session established by the logon service.
Wait request (wait)
Wait request is used to maintain an established connection during idle periods to avoid automatic termination from a traffic timeout.
Registration request (register)
Registration request is used to add and maintain routing tables of C12.22 relays. This is covered later in the description of routing.
De-registration request (de-register)
De-registration request is used to remove a routing table entry of a C12.22 relay. This is also covered later in the description of routing.
Resolve request (resolve)
Resolve request is used to retrieve the native network address of the C12.22 node. This native address can be used to communicate with other nodes on the same network segment.
Trace request (trace)
Trace request is used to get a list of relays capable of forwarding messages to a target node. This is intended mostly for diagnostics.
The Impact of C12.22 on Internet Metering
There are alternative methods to C12.22 by which meter data is transported over a network. Instead of wrapping C12.18 or C12.21 protocol transactions in an existing network transport protocol such as TCP, the committee decided to use C12.22 for three main reasons: improved security, reliability, and speed.
Improved Security
The first reason is improved security. In C12.18 the password is sent unencrypted. This is not a problem for a point-to-point connection from a handheld device to an optical port on a meter, but when data is transmitted over the Internet, it’s a serious security problem. A hacker with a computer loaded with freely available packet sniffing software can look at the packet and see the password. C12.21 has an alternative authentication mechanism, which provides for encrypted authentication, but the encryption is only used for authentication and all subsequent data reads and writes are done unencrypted. With a point-topoint connection via dialup telephone lines, this is not a problem because intercepting such communications is very difficult, but if the data is transmitted over the Internet, we once again have a problem because hackers can easily intercept the data. In both of these cases, the problem created is that a hacker, having successfully monitored the login, can now freely interfere with the meter and the automated meter reading (AMR) system. C12.22 enables data encryption without requiring it, so no additional communications resources are used until encryption is actually used.
Reliability
Reliability is the second reason C12.22 is preferred over wrapping C12.18 transactions in TCP. Remember that C12.18 was intended for use over a point-to-point connection via an optical connection with very low error rates. In a typical network, errors and retransmissions are common and the data frames may arrive out of sequence. You might get the second half of the message before you get the first half. TCP takes care of these details and hides their effect to a point, but there is a cost. First, every TCP connection requires a three-way handshake to open the connection. Then, every application layer request that gets transmitted over TCP must be delivered completely before it is passed to the receiving point application layer. If the second half of the message arrives first, it is not available to the application layer until the first half also arrives. This is a useful property of the TCP transport service, but it has consequences. C12.18 and C12.21 both say that if an expected reply is not received before the traffic timeout period expires; the request should be retransmitted. If this happens, then the second response is also blocked until the first transmission is satisfied (by receiving the missing first half of the message) or the session times out at the TCP layer.
Speed
The third reason is speed. C12.22 provides for messages that do not require a session. This means a single transaction (see Figure 2) can support an authentication and read billing data request without the usual overhead of a table read transaction (see Figure 3). It’s important to note that this applies whether or not the data is transmitted over any Internet segments. Because of this overhead, a radio network built using C12.21 or C12.18 may be more expensive to operate because radio networks are often billed by the amount of airtime used.
Conclusion
The utility industry trend is to read increasing numbers of meters remotely using various types of networks. As communications options diversify, some kind of packet-based network is more frequently used for this purpose. The C12.22 standard accommodates this diversity without becoming a nightmare for manufacturers, utilities, and regulators. This article covered just a few of the many facets of C12.22. If you would like to learn more, the entire draft standard is available on the web at: www.nertec.com/standards/ansic1222/index.htm and also at www.forums.nema.org/~ansi_c12-17. Our meetings are open, and we welcome your participation and comments.
About the Author
Edward Beroset has been working with computers and software for over 20 years. Edward is the manager of the software and test group at Elster Electricity, where he has worked for seven years. Prior to that, he worked in BIOS development at Compaq. He serves on IEC and ANSI electricity metering protocol standards groups and chairs the working group which is responsible for creating the C12.22 standard. He is a member of both the IEEE and the ACM, has published several articles and holds several US and foreign patents.
